API Whitepaper Selection

The API revolution continues! API Whitepaper Selection

25+ pages of knowledge for API enthusiasts. Learn about exciting topics such as API Development, Management, Design and Platforms & Software as a Service

API Conference @api_conference @apiconf #APICON apiconference.net content

API Design

The demand for realtime APIs 3 Realtime API Family helps us to reduce complexity by Kieran Kilbride-Singh

API Development

What APIs Can and Cannot Do 6 How to avoid common API misconceptions and the resulting disillusionment by Erik Wilde

Go for gRPC? 11 Develop gRPC services with Go by Rainer Stropek

API Platforms & Software-as-a-Service

X-Road – The Free and Open Source Data Exchange Layer 17 A centrally managed distributed Data Exchange Layer between information systems by Petteri Kivimäki

Regulation as a Service 21 Rethinking APIs by Khallai Taylor

API Management

Shopware 6 and the new API-First Approach 23 Putting the API on the Acid Test by Thomas Eiling

APIs have Properties – find and test them! 26 Taking executable specifications seriously by Dr. Michael Sperber WHITEPAPER API Design

Realtime API Family helps us to reduce complexity The demand for realtime APIs

Looking to 2020 and beyond, the proportion of data produced and consumed in realtime is growing exponentially

by Kieran Kilbride-Singh defines it as anything that happens in under 100ms as this is typically the threshold for perceiving something IDC predict that by 2025 1/3 of all data produced glob- as happening immediately. ally will be realtime. The engineers and organizations Any API designed such that data flowing from pro- that make up the realtime ecosystem, Ably included, ducers to consumers happens in the shortest amount of have yet to agree on how we describe the APIs we’re time possible can therefore be described as realtime. creating and consuming that are powering this growth. Ably has settled on realtime API as an umbrella for The problem is that there are various ways to describe event-driven, streaming, pub/sub, push, and other APIs. APIs that provide realtime functionality. We’ve seen many more than four ways of describing API evangelist Kin Lane, and many others, have been this, but these are the most popular. It’s why we call it writing and talking about these new types of APIs for a the Realtime API Family (Image 1). while. Event-driven seems to be the most common descriptor. Gartner has adopted the term, stating that by 2020 50 % of all managed APIs will be event-driven. But still today there is no consistency or consensus between what terms like realtime API, event-driven API, or streaming API refer to. Often they’re used interchangeably. As an engineering team and API provider working on a global pub/sub messaging platform, we work with these ideas everyday. Talking to our users we see the language they use to describe both what we do and what they achieve using our APIs. And we’ve watched discussions around event-driven architecture, webhooks, and streaming data proliferate. Over the years we’ve thought extensively about the best terminology to use and arrived at what we call the Realtime API Family

Defining realtime When it comes to realtime in the context of user interaction, it can be defined as a function or interaction perceived as immediate. As a concept in this context then, realtime is easy enough to understand. Ably Image 1: Realtime API Family

www.apiconference.net 3 WHITEPAPER API Design

Image 2: Ably’s Pub/Sub Channels API acts as a serverless message bus Streaming APIs Push APIs A stream is a means of transporting data. Streaming is a Push is another umbrella term for every API that is real consumer pattern that describes how consumers receive time. events through a stream. But it’s just a producer messaging pattern. It means A streaming API will commonly address issues of data that data is pushed upstream over a connection, versus integrity with: a pull mechanism used by the request/ response pattern. • Message ordering - ensure messages are delivered in An example is helpful. A push notifications API Im-( the order they were published age 3) is an example of a push API. Or a sporting event • Stream continuity / resume - upon disconnection, might send a single score update that traverses multiple resume from the disconnected point within a set pe- systems via push APIs, resulting in millions of messages riod of time to global fans within a few hundred milliseconds. • Contiguous serial numbers - a simple series of `ACK` Push can also refer to triggering a new request as with a or `NACK` responses, each addressing a contiguous Webhook. Or it can mean ‘push subscription’ – i.e. a pro- sequence of messages ducer needs to reach out to a consumer. WebSub is an example of this. But that’s beyond the scope of this article. Kafka offers a streaming API following this model for internal systems. Event-driven APIs Event-driven is an architectural design pattern that de- Pub/Sub APIs fines how a system processes data. Pub/Sub (Publisher/Subscriber) is an infamous messaging design pattern. When it debuted in 1987 it solved loose decoupling of servers. The earliest distributed systems used to send events between servers using Pub/Sub, but all within reliable networks. This pattern operates by publishing API 365 Workshop: messages on a topic (or channel) within a message bus, Building APIs and managing and subscribers can listen for events based on those top- them with serverless, containers, ics. Pub/Sub is over 30 years old now. The design makes API gateways and Azure no attempt to define semantics around ordering or Dr. Roberto Freato (Freelance) continuity (loss of connection). While it’s still a pattern used widely today, these are issues that must be The main focus of this workshop is to considered and addressed in our world of unreliable have a look into the API ecosystem connections. to approach the problem with good insights and to organize things to be Ably provides a pub/sub (Image 2) API following this reliable, available and to reduce the model but with guarantees around ordering, continuity, overall governance effort. idempotency, and more.

www.apiconference.net 4 WHITEPAPER API Design

event in an event-driven world triggers a chain of events which must be processed downstream, extending through the entire data supply chain. All components in this supply chain are reactive, rapidly responding to events and per- forming onwards processing. The time-bound, reactive nature of this data supply chain causes increased engineering and infrastructure complexity. And when compared to REST APIs following the request/response model, the complexity is inverted and put onto API producers rather than API consumers. However, that’s a conversation beyond the scope of this article. But it’s something we’ve spoken about before at API

Image 3: Ably’s unified push notifications API And so we arrive at Realtime APIs It simply states a system should be responding/re- Streaming, Pub/Sub, and Push are all patterns that can acting to events as they happen. Streaming, Pub/Sub, be delivered through event-driven architecture. But the and Push are all messaging patterns that can delivered outcomes of streaming, push, pub/sub, and event-driven through an event-driven architecture. As such they can are all realtime functionality. They’re all means of get- all fall under the umbrella of event-driven APIs. ting data from producer to subscriber in the shortest Most of us know what an event-driven API is but possible time. So we can call them realtime APIs. an example never hurts. Unlike traditional request/re- But you can’t have a realtime API unless it’s delivered sponse APIs where data is requested, event-driven APIs as an event-driven, pub/ sub, streaming, or push API. push data from a producer to a consumer. They can be Hence how we’ve settled on the umbrella term of real- quite simple or very complex. time API to encompass them all. In the above example a retailer needs an event-driven architecture to respond to things as they happen. An Navigating complexity and fragmentation As you can see, it’s easy to use these terms interchangeably despite them all being different. The realtime ecosystem is still maturing and changes all the time. Eventually we believe developers and organizations will naturally come to a shared and standardized terminology for APIs Do we have a Packaging designed to deliver real time functionality. Problem? Until then, the Realtime API Family helps us to reduce complexity when we explain our cloud infrastructure Maxim Zaks (Self Employed) and APIs to the developer community, our users, and our potential customers. Designing an API is a complex ende- avour. It contains of many details and considerations. One of such considerations is: How do we package data we are sending around? In this talk, we Kieran Kilbride-Singh (Product Marketing Manager) will discuss different packaging techniques like CSV, is writer and marketer with enough technical know- XML, JSON, Protocol Buffers and FlatBuffers. We will how to be dangerous in a GitHub repo. He first flexed evaluate the benefits and pitfalls those techniques his fingers writing about topics like interoperability in embedded IoT devices. Nowadays he thinks and bring to the table. writes about realtime infrastructure, event-driven APIs, and next-generation connected experiences for Ably.io.

www.apiconference.net 5 WHITEPAPER API Development

How to avoid common API misconceptions and the resulting disillusionment What APIs Can and Cannot Do

APIs sometimes are perceived as having almost magical properties: Since they are so essential to digital transformation, and all of our digital experiences today are powered by APIs, the conclusion is that once you have and use APIs, all the wonders of digital transformation are simply going to happen. Of course that's not necessarily the case, and the purpose of this article is to explain some of the useful things where APIs play an essential role, but where APIs are necessary but not sufficient.

by Erik Wilde er solutions. By definition, APIs (in their modern sense of "networked interfaces") are essential in this picture, Working with many global organizations in the API because untangling means that the resulting modular space, most recently as part of the Axway Catalyst structure needs communications to function, and these Team, our role very simply is helping customers make will be using APIs. good decisions. This of course also involves helping cus- The hard work in this picture, though, is to come up tomers avoid bad decisions. One such bad decision is with a good modularization where the resulting struc- to have an incomplete understanding of the complexity ture follows structured design principles. There are of digital transformation and APIs, and to expect too many theories and practices how to come up with a much from just "doing APIs" without making sure that "good" structured design that represents a complex sys- all necessary factors for success are in place. tem. The hard work of doing it will lead to components I'll explain 5 common misconceptions about the that then communicate through APIs, but these APIs are powers of APIs. We expect these good things to hap- an effect and not the cause of the untangling. pen when using APIs, but we also have to understand Sam Newman's "Monolith to Microservices" pro- that they are not quite as simple, and that success will vides a good guide how to systematically decompose depend on additional complexities also being addressed. a monolithic system into one that is composed out of Better understanding these complexities from the very many communicating components. It is telling that the beginning will help to avoid disillusionment, and will book has a lot to say about decomposition patterns and also help to make sure that all necessary ingredients for a successful API journey are considered when starting the journey.

#1: Untangling Monoliths! Of Course! Of course APIs are essential for improving modularity, allowing entangled IT systems to be decomposed into loosely coupled ecosystems and thus being easier to maintain and extend. Of course! (Image 1) One common motivation to use APIs is to get rid of monolithic solutions that often have a variety of problems associated with them, most importantly being hard to change, hard to scale, and hard to integrate with oth- Image 1: Untangling Monoliths

www.apiconference.net 6 WHITEPAPER API Development

Scaling things better is one of the reasons why APIs may be considered. When you have decoupled components, the reasoning goes, it becomes easier to scale up those parts that need scaling, while other parts of the system can be left alone. In many cases when people consider microservices or serverless, one of the main values they might be interested in is scaling. For microservices, you then might have to invest in how to implement scaling with something like Kubernetes. For serverless, scaling works easier, where given a sufficiently capable platform, scaling can be done transparently and is simply a question of how often serverless functions get invoked. Since APIs are essential for both microservices and Image 2: APIS pneumatic tubes serverless (they are part of the definition of what these things even are), once again one might come to the con- strategies, but focuses little on how to design commu- clusion that with APIs in place, scaling becomes much nications between the resulting components. The suc- easier. Once again, this is not necessarily the case. When cess of a good decomposition is defined by identifying it comes to scaling, and in particular the selective scal- the right components, and then carving out parts in ing that API-based components can deliver (only scal- ways that allow the overall system to remain functional ing those components that need to be scaled), then once throughout the transition. APIs will be created as a side- again architecture is much more important than APIs. effect of doing this, but success is a function of decom- A little while ago, when Representational State Trans- position patterns and strategies. fer (REST) was a much-discussed topic, one often over- The worst-case scenario is that APIs will actually looked aspect of it was that one of the REST constraints make things worse, because decomposition was not is for services to be stateless. That way, each invocation done properly. In this case, the newly created API-based of a service strictly is just a function of the invocation architecture suffers from chatty APIs, and the APIs (and not of some shared conversation state). This de- themselves are not all that useful for unlocking new sign allows scaling to be simpler, because services can value. This result often is referred to as a "distributed be scaled without having to keep track of conversation monolith", but this result cannot be attributed to "APIs state. This is a useful design, but it is one that depends negatively impacting performance"; it is just bad system on service designers specifically creating stateless de- design. In addition, bad API design choices may further signs. For services not being stateless, scaling gets con- negatively impact the resulting system, but the root siderably harder because requests cannot as easily be cause in this case most often is a design where compo- used for scaling up as required. nents are not loosely coupled. As before, there also is a worst-case scenario. If the system design does not take shared state into consid- #2: Scaling Up! Of Course! eration, scaling may have unintended side-effects. It still Of course APIs allow you to more easily scale IT re- may be possible to scale the component on demand, but sources by only scaling up those parts that actually need scaling up the context that it needs (because it is not to be scaled. Of course! (Image 2) stateless) may have an unfortunate ripple-effect. This possibly can be mitigated by sophis- ticated state-sharing approaches, but the underlying problem often is that of "implicit shared state".

#3: Monetization! Of Course! Of course APIs can be new sources of revenue, allowing cost-effective ex- perimentation with digital offerings and creating new revenue streams beyond the traditional sources of income. Of course! (Image 3) There is an abundance of presentations that highlight how some companies make a lot of money with their APIs. The most prominent ex- Image 3: Monetization amples may be Stripe and Twilio.

www.apiconference.net 7 WHITEPAPER API Development

value manifests itself in directly API-generated revenue, this introduces an incomplete value analysis for the API journey. Nobody has yet figured out the perfect formula how to precisely evaluate the value of an API (so that investments could be targeted towards API-enabling those capabilities first that have the biggest potential), but it is cer- tainly not as simple as looking at the revenue generated through API access. Fully understanding value chains and evaluating and predicting their success never has been a hard science for as long as organizations have started planning and building them. This is no different for digital value chains, so make sure that you take a holistic view.

#4: Communications! Of Course! Image 4: Difficult communication Of course APIs are the way how to communicate in digital environments, and via Some of these presentations talk about the "API Econ- APIs all capabilities can easily interact throughout the omy" and then jump to the conclusion that this means entire organization and beyond. Of course! (Image 4) that money is being made by charging for API access. APIs are a language: They allow peers to communi- For organizations considering their API journeys, this cate in order to achieve some goal. As such, APIs sup- looks like a tempting route, opening up new sources of posedly should allow teams to become more decoupled, revenue just by exposing APIs and charging for them. thereby reducing the communication and coordination Some API vendors also rather aggressively advertise this overhead. In an ideal scenario, inter-team communica- sort of direct API-based income, hoping that potential tions entirely happen through APIs or associated chan- customers will factor this into their ROI analyses. nels (such as documentation and support channels). In However, the reality is that it is a small minority of reality, things often are a bit trickier, and that's in part cases where API value manifests itself directly in paid API access. In the majority of cases, API value manifests itself in enabling more value chains, and a culture in which these value chains can be built rapidly and with little coordination. For this reason, the popular "API-as- a-Product" moniker is a rather poor naming choice, as API for the masses: Challenges it seem to imply that the API itself is a product that can in exposing a public car API be monetized. Talking about "Product as API", on the Holger Dietrich, Katja Weisheit other hand, makes it clear that value is created by prod- (pentacor GmbH) ucts, and that APIs simply are the connective tissue that allows this value to be unlocked and used more easily. The combination of business functions Once again, it is undoubtedly true that APIs are nec- from different companies offers im- essary for value being created in today's digital world, mense potential for innovation and new and that being better with APIs increases your chances business models. Entire, cross-industry of realizing more value. But the value is in what you ecosystems are emerging. If you want do and how you allow these things to be composed in to be part of these ecosystems, you digitalized value chains. If what you do has little inher- have to open up your business and ent value, then your efforts of digitalizing your scenario think about publishing APIs. They offer well-defined endpoints and provide may not create a lot of additional value. And even if public access to business functions what you do has a lot of inherent value waiting to be and objects. However, it’s important to consider that realized, it is unlikely that exposing just the right API data is extremely valuable and highly sensitive for is what keeps you from realizing that value. What we many organizations. Our field report shows how an see much more often are companies struggling to do the automotive manufacturer’s car API is exposed using right business and organizational changes, so that the an API management platform. We discuss both, latent value in their products can be realized by building technical and organizational challenges and our best practices to solve them. Moreover, we want to talk great and valuable experiences around them. about the increased demands for security, availability, Of course, we also have a worst-case scenario here. and stability. If the perception of API monetization is such that API

www.apiconference.net 8 WHITEPAPER API Development

Image 5: Organization because the language of the API needs to be at a useful proposition why others might use them, and solving level for everybody involved. that problem in the easiest way possible then becomes For example, one scenario we see often is that API the guiding principle for identifying and designing APIs. efforts start on the IT side. One initial initiative may be While this may sound easy, it often is a hard problem to to create "System APIs", which often are relatively low- solve, because it requires a functioning dialog between level APIs representing capabilities provided by certain business and IT. This may be a natural thing for com- systems. This often translates to a poor experience for panies born digital, but it can be a real challenge for those teams a bit further away from system details: They companies where business and IT are still two relatively are looking for solutions to their problems, and not for disconnected parts of the organization. access to implementation details. It often takes quite a The worst-case scenario is that technical APIs deepen number of these "System APIs" and their orchestration the rift between business and IT. IT thinks they are de- in specific ways to accomplish tasks that from a business livering value because they make capabilities available. point of view should be relatively easy to do. There is a Business thinks "this is just another tech thing" because "language mismatch" of the APIs being built from the they don't see clear business value being exposed in the system point of view, and the API consumers looking for technical APIs. The remedy for this is for both sides to APIs that address their domain problems. better understand each other, and to work towards es- This problem is best solved by looking at APIs as tablishing and using a shared language. IT needs to fo- business-level capabilities: They must have a value cus their efforts on exposing APIs that have a clear value

www.apiconference.net 9 WHITEPAPER API Development

proposition and accomplish a business purpose. Busi- harder challenge than designing the APIs that they will ness needs to start "talking API", not to the point where produce and need. And of course, even if an organiza- they design JSON that they expect as responses, but to tion has been changed successfully, it still takes careful the level where they think in terms of designing and de- design and execution of an API strategy and an API pro- livering products as digitalized value chains, based on gram. But in our experience, once it comes to these API- existing APIs, and exposing their own APIs. That is in specific issues being the remaining problem, the hardest essence what a true "API Culture" is all about. part of transformation has been solved. The worst-case scenario for this is that organization #5: Organizational Issues! Of Course! leaders see digital transformation first and foremost as a Of course APIs can help with improving the way how technical challenge, and focus on technology indicators. teams communicate and how the organization can in- Once APIs are being created, the assumption then is that novate. Of course! (Image 5) good things will follow. We see many organizations APIs are popular these days because, among other losing months or years of precious time because they reasons, large organizations are slow at adapting to don't fully appreciate the implications for the business changes, and more modern organizations that are show- and organizational pillars. In our work with large com- ing how to be faster are doing so by re-organizing them- panies, a substantial share of our time is to make sure selves, re-organizing the way they build products, and that all the pillars necessary for digital transformation this reflects itself in API-centric organizations and cul- (business, organizational, technology) are addressed, tures. There is no way escaping Conway's Law, meaning and from that perspective APIs simply are a sideeffect of that in order to build something that is non-monolithic digital transformation, and not a cause. and can be changed more easily, you need an organization that has the same structural properties. Conclusions APIs play an essential role in this picture, because they This article presents 5 common misconception about greatly reduce coordination overhead. Instead of doing what APIs can do, and makes the point that they actu- one-off "integration" projects, capabilities are exposed ally can do these things, but not by themselves. APIs are through APIs, and anybody needing them can simply necessary but not sufficient for many important chal- access them, ideally without ever talking to the team lenges and opportunities in today's increasingly digital that owns that capability. This approach scales better, organizations. The most important takeaway of this and furthermore creates an abundance of options when article is that it always takes a holistic view: APIs are it comes to teams designing new experiences and look- part of many solutions in the digital space, but they are ing for existing capabilities that they can leverage. In a never the solution themselves. Luckily, organizations perfectly functioning organization, teams are decoupled nowadays can benefit from a lot of experience, they can and can work at their own speed, delivering and evolv- choose between many available products, and they can ing products as needed. rely on trusted advisors for their journey. All these is- In reality, changing a large organization to this ideal sues discussed above are very real and relevant challeng- picture of decoupled and empowered teams is a much es for many organizations today. Make sure that your API strategy and your API program take a holistic view. Many reports about "digital transformation initiatives" show high failure rates, and by looking beyond just the technical aspects, you drastically improve your chances to make meaningful changes that truly transform your API Workshop: organization. This article is based on a presentation given at the API Security with OAuth 2.0 and Conference in Berlin in October 2019. OpenID Connect – Get started The slides are available online at http://dret.net/lec- as an API Security Expert tures/apicon-2019/api-limits Matthias Biehl (API-University.com)

This workshop offers an introduction to API security with OAuth 2.0 and Ope- nID Connect. After taking this workshop Erik Wilde works for Axway as part of their Catalyst you will understand the foundations and team. The goal of this team is to help customers make current best practice of API security. good decisions by helping them on their API journey. You will get to know the actors in OAuth and OpenID A core aspect of this role is to make sure that custom- Connect, the endpoints and tokens involved and how ers have an API strategy, establish an API program, and use API guidelines to cultivate and evolve their API land- these elements interact in so-called flows. A picture scape. Part of this journey also is understanding that APIs them- says more than 1000 words, so we visualize these selves are no silver bullet, and that APIs can only realize their flows as easy-to-understand sequence diagrams. full potential when they are managed in the greater context of digital transformation.

www.apiconference.net 10 WHITEPAPER API Development

Develop gRPC services with Go Go for gRPC?

When most people think of APIs for microservices, they think of HTTP-based, RESTful Web Services first. The REST paradigm is the predominant one when it comes to services publicly available on the Internet that many development teams deal with. It also fits quite well if the problem can be traced back to CRUD (Create, Read, Update, Delete) services in the broadest sense.

by Rainer Stropek in the background should be the same, only the communication protocol can be chosen by the user depending In practice, however, REST does not fit every problem. on the technology and use case. gRPC is a more general protocol that can be used to call Of course, a modern RPC system like gRPC is very arbitrary functions across process or network bounda- different from its ancestors from the 70s. It has become ries. In this article I describe how to use the Go pro- much more powerful and supports, for example, the ef- gramming language to develop efficient gRPC services ficient transmission of complex data structures using that are easily accessible from other platforms such as protocol buffers (ProtoBuf [1]) and streaming in both .NET and C#. communication directions. Frameworks for developing gRPC servers and generating gRPC clients are avail- Why gRPC and not REST? able for all widely used programming languages [2]. In Many microservices don't care about storing data in da- my experience the tools for code generation are better tabases, but offer different functions. Accordingly, it is and more stable than many of the code generators for difficult to force them into the corset of REST. Is the ac- Swagger aka Open API. In addition, gRPC is based on tivation of a heating function on an IoT device an insert HTTP/2, which gives a comparatively better perfor- or update? How does a service for restarting a VM fit mance for communication between microservices. into the concept of REST? How do you model a service After this short introduction, I will not go into the for sending SMS messages so that the API can be easily basics of gRPC and ProtoBuf in this article, as they have understood by others? The concept of RPC is ancient already been described elsewhere. Let's now take a look and more general than REST. All operations are traced at the development of gRPC services with Go. back to a collection of commands that receive parameters and return the result. Why Go? The advantage of this generic approach is that it can Go is primarily used for the development of web ap- be applied to a larger number of problems without hav- plications [3]. The focus is on API and RPC services, ing to squeeze them into a poorly fitting architectural dynamic HTML generation follows with a slight gap. principle. The disadvantage is that each RPC interface Go is one of the leading programming languages in can be modeled differently, while RESTful APIs - where terms of container and cloud technology (e.g. Docker, they conceptually fit - are more consistent and therefore Kubernetes, Terraform). A platform such as .NET is easier to understand and use. In practice, I recommend much more generally usable compared to Go, where avoiding discussions about one or the other. There is other application areas such as UI clients, mobile apps, nothing to be said against offering a cloud service with a games etc. play an important role besides web pro- RESTful API and a gRPC API in case of doubt. The logic gramming.

www.apiconference.net 11 WHITEPAPER API Development

Specialization is a double-edged sword for program- rialization of data for its transmission and/or storage. ming languages. On the one hand, it is a disadvantage The technology is therefore used similarly to JSON or because a company cannot consistently use one lan- XML, but it is much more optimized for performance guage for all application areas. On the other hand, it is through more compact, binary data structures. In addi- an advantage because the language and the libraries and tion to data structures, ProtoBuf also allows the defini- tools available for it can focus on a specific application tion of services (=APIs) that use the data structures for area and are correspondingly good. parameters and return values. These services become the In my opinion, Go is very well suited for the develop- gRPC API. ment of microservices that offer RESTful or gRPC APIs. In this article I use the current version 3 of ProtoBuf Go is a simply structured language that emphasizes (aka proto3). In practice you still find proto2 in exist- consistency. Stability is especially important in Go, and ing applications, but new solutions should be based on APIs evolve more slowly in Go than in the fast moving version 3. UI world. By generating native code instead of Intermediate Installing the compiler Language, good start times and good runtime perfor- Enough with the theory, let's look at an example. Be- mance can be achieved. Go generates a compact exe- fore we can get started, we need to download and install cutable file for a microservice, which - if you want it the latest version of the ProtoBuf compiler (aka protoc) to - even runs without any external dependencies. The from GitHub [4]. Don't forget to add the compiler's bin compiled gRPC client shown later in Listing 4 has with- directory to the PATH environment variable so that out debug information only about 8MB and you don't protoc can be found on the command line. Then, we need to install any frameworks or other system require- install the Go plugin for protoc with go get -u github. ments to run it. This compactness and performance are com/golang/protobuf/protoc-gen-go, which is responsi- advantages when using microservices in cloud comput- ble for generating go code. The Go plugin can be found ing environments. in the directory $GOPATH/bin (or %GOPATH%\bin So there are good reasons to consider Go when devel- on Windows). Also make sure that this directory is ref- oping gRPC Services. erenced in the PATH environment variable. You have already experimented with gRPC for .NET ProtoBuf and wonder why the preliminary work at Go is so com- The development of a gRPC API starts in Go as in plicated? With .NET you had to do exactly the same all other languages with ProtoBuf files. ProtoBuf is a thing, only Visual Studio did all the steps without you mechanism for language and platform independent se- noticing. I use Visual Studio Code (VSCode for short) for Go development and therefore the above mentioned steps are necessary to set up the development environ- Listing 1: greet.proto ment. A tip for all those who use VSCode like me: There are some plugins for VSCode that add proto3 file sup- syntax = "proto3"; port to the editor. Just search for ext:proto3 in the Ex- tensions Manager and choose the one you want from // Language-specific option used go code generator. the available VSCode extensions. option go_package = "greet"; Simple proto3 file package demo; Proto3 files always follow the same naming conventions regardless of the programming language used: // The greeting service definition. service Greeter { • File names follow the snake_casing_name scheme. // Sends a greeting The same applies to field names and enum values, rpc SayHello (HelloRequest) returns (HelloReply); whereby capital letters are used for the latter. } • CamelCasing is used for message names, enums and service names. // The request message containing the user's name. • We recommend that you use the keyword package to message HelloRequest { divide messages and services into namespaces so that string name = 1; identifiers are not used twice. } These naming conventions apply regardless of the pro- // The response message containing the greetings. gramming language you use to program gRPC. The message HelloReply { code generators will convert the ProtoBuf naming string message = 1; conventions into the appropriate naming conventions } for the target language (for example conversion from camelCase to PascalCase).

www.apiconference.net 12 WHITEPAPER API Development

Listing 1 shows a Hello World proto3 file that de- Listing 2: Implementation of the gRPC fines a service with one message for each parameter service and return value. You compile it with protoc ./greet. proto --go_out=plugins=grpc:. The parameter value package main plugins=grpc tells the ProtoBuf Go plugin to generate gRPC compatible code. The result is a filegreet.pb.go import ( with generated Go code, which should not be modified, "context" "fmt" because it is generated every time the plugin is compiled. Worth mentioning in Listing 1 is the option go_pack- "github.com/Samples/BeyondREST/GoGrpcServer/greet" age. The concept of ProtoBuf Packages cannot be ) directly assigned to Go Packages. Therefore, it is rec- ommended to explicitly specify the go package for the type service struct { generated code in proto files. } The Greeter.SayHello method shown in Listing 1 is a so-called Unary RPC Call. The client sends a single func (s service) SayHello(ctx context.Context, req *greet.HelloRequest) (*greet.HelloReply, error) { request and the server responds with a single response. // If you are new to Go, you can learn more about context. gRPC can also handle client-side, server-side and bidi- // Context at https://blog.golang.org/context and rectional streaming. This will be discussed later in this // https://golang.org/pkg/context/. article.

return &greet.HelloReply{ Generated Message Structures Message: fmt.Sprintf("Hello %s", req.Name), The Go-code generated from the proto3 file is easily }, nil readable. Everything that starts with XXX_ can be ig- } nored. These elements (e.g. fields in ProtoBuf messages) are necessary implementation details, but are not part of the public API. The proto3 messages become Go structures (struct). The Listing 3: Starting the gRPC server properties of the individual fields are mapped in Go as tags for the protobuf and json packages. Here is an example package main of the code generated from HelloRequest.Name: Name import ( string `protobuf: "bytes,1,opt,name=name,proto3" json: "context" "name,omitempty"`. "fmt" "io" gRPC Service "log" A Go Interface is generated for each service of the proto "net" file. In the case of the example from Listing 1, this is the "time" GreeterServer interface. As a developer of the gRPC service, you have to implement the methods of the interface "github.com/Samples/BeyondREST/GoGrpcServer/greet" and do the actual work that the service is supposed to "google.golang.org/grpc" provide. Listing 2 shows a simple Hello World imple- ) mentation of the gRPC service from Listing 1. Listing 3 contains a simple variant of the code that [...] // Add code from Listing 2 (without import and package) can be used to start the gRPC server. In practice, this func main() { listen, err := net.Listen("tcp", ":8080") if err != nil { panic(err) }

// register service The rocky Road of the OpenAPI server := grpc.NewServer() AST greet.RegisterGreeterServer(server, service{}) Dr. Vincenzo Chianese (Stoplight) greet.RegisterMathGuruServer(server, mathGuruService{}) Let‘s go through my last 5 years in the // start gRPC server API industry as a tooling company de- log.Println("starting gRPC server...") veloper seeing how the OpenAPI 2 and server.Serve(listen) 3 standards have their own quirks and } made my life a mess.

www.apiconference.net 13 WHITEPAPER API Development

code will be more complex as you will add, for example, Listing 4: gRPC Client TLS encryption (see e.g. [5]), code for controlled shut- down of the gRPC server [6], or code for authentication package main (see e.g. [7]). The code in this article is intentionally kept simple so that we can concentrate on the core functions import ( of gRPC. "context" "log" gRPC client The client for our gRPC service was generated by pro- "github.com/Samples/BeyondREST/GoGrpcClient/greet" toc. We can use it without having to implement any in- "google.golang.org/grpc" terfaces. Listing 4 calls the gRPC service defined above. ) When calling the gRPC method SayHello, the context. Context [8] must be considered. It has already been in- func main() { cluded in Listing 2. This type allows us to influence the conn, err := grpc.Dial("localhost:8080", grpc.WithInsecure()) behavior of the gRPC connection and to specify things if err != nil { like timeouts or to cancel the gRPC call. panic(err) } Streaming defer conn.Close() While the examples shown so far demonstrate the basic principle of gRPC in Go quite well, they only scratch client := greet.NewGreeterClient(conn) the surface of what gRPC can do. In this article I would response, err := client.SayHello(context.Background(), like to discuss an important, advanced feature of gRPC: &greet.HelloRequest{Name: "FooBar"}) Streaming. gRPC can do three variations of this: if err != nil { panic(err) • Server-side streaming: The server does not respond } with a single response, but with a stream of responses. log.Println(response.Message) • Client-side streaming: The client does not send a } single request, but a stream of requests. The server responds with a response. • Bidirectional streaming: The client initiates communication by calling the gRPC function and then sends a stream of requests. The server responds with Listing 5: Proto-File with streaming

syntax = "proto3";

option go_package = "greet";

package demo; The 3 Axes of Scaling APIs Milecia McGregor (Flipped Coding) [...] // Greeter Service shown in previous code samples It’s great when your app starts to get // Note streaming result more users. That means your product is a success and people like it. Sometimes service MathGuru { this rush of users leaves companies rpc GetFibonacci (FromTo) returns (stream NumericResult); struggling to keep their applications up } because they weren’t built to handle this kind of usage. Scale wasn’t a consideration when the app was message FromTo { initially built. This happens all the time and API de- int32 from = 1; velopers need to know how to manage scaling up an application. Whether you’re starting with a monolith int32 to = 2; or cloud-based application, there are 3 major tech- } niques you need to know how to use to scale an API. These 3 techniques will be able to take your app from message NumericResult { handling a few thousand users to millions. By the int32 result = 1; time you leave this talk, you will be know everything } you need to scale any API and you’ll have the 3 core techniques to make it happen.

www.apiconference.net 14 WHITEPAPER API Development

a stream of responses. The two streams are independ- is not complicated. The degree of complexity of the code ent of each other and can work interlocked. This is not increased by gRPC or Go, it results from the ap- means that the client does not have to have sent all plication logic to be provided by the gRPC API. the requests before the server begins to send respons- To demonstrate the platform independence of gRPC, es. in Listing 7 I show what a client for our streaming API in C# looks like. The gRPC client MathGuru.MathGu- Let's have a look at an example. In this example, we re- ruClient was generated by Visual Studio 2019 from the turn the numbers of a Fibonacci sequence from a gRPC same proto3 file we used for Go before (Listing 5). In server. To make things more interesting, let's pretend the C# implementation it is noticeable that to consume that it takes longer to calculate the individual numbers. the streaming API the new C# 8 function await foreach This allows us to use streaming. After all, the client can already process the first numbers, even though the server is still in the process of calculating the next results. In this example, the server is streaming responses to the Listing 7: Consuming the Streaming client, so it is server-side streaming. API in C# For space reasons, the rather simple source code for using Grpc.Core; the iterator that calculates the Fibonacci sequence is not using Grpc.Net.Client; printed here. If you are interested, you can read it in- using GrpcDemo; cluding unit tests on GitHub [9]. using System; Listing 5 shows the extended proto3 file with the using System.Threading.Tasks; streaming service. Note in particular the keyword stream when defining the method GetFibonacci. It indi- namespace GrpcClient cates that the method does not return a single response, { but a stream of responses. class Program Listing 6 shows the implementation of the streaming { method. As you can see, even with streaming, the code static async Task Main() { AppContext.SetSwitch( Listing 6: Implementation with "System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport", streaming true);

func (mgs mathGuruService) GetFibonacci(fromTo *greet.FromTo, // Create channel. stream greet.MathGuru_GetFibonacciServer) error { // Represents long-lived connection to gRPC service. if fromTo.From > fromTo.To { // The port number(5001) must match the port of the gRPC server. return status.Error(codes.InvalidArgument, "FromTo.From must be <= FromTo.To") // Tip: In ASP.NET Core apps, use gRPC client factory } var channel = GrpcChannel.ForAddress("http://localhost:8080");

fib := mathalgorithms.NewFibonacciIterator() var mathClient = new MathGuru.MathGuruClient(channel); for fib.Next() { await ServerStreaming(mathClient); if fib.Value() < fromTo.From { } continue } private static async Task ServerStreaming( MathGuru.MathGuruClient mathClient) if fib.Value() <= fromTo.To { { stream.Send(&greet.NumericResult{ // Note usage of new using statement (C# 8) Result: int32(fib.Value()), using var fibResult = mathClient.GetFibonacci( }) new FromTo() { From = 10, To = 50 }); time.Sleep(250 * time.Millisecond) continue // Note usage of new streaming enumerable } await foreach (var fib in fibResult.ResponseStream.ReadAllAsync()) { break Console.WriteLine(fib); } } } return nil } } }

www.apiconference.net 15 WHITEPAPER API Development

can be used. This makes the code very easy to read and mon programming languages and are of high quality. write. As hopefully you have seen from the examples shown If you're interested in what bidirectional streaming above, developing gRPC code with Go is easy to learn. looks like, you can take a look at a more comprehen- At runtime, gRPC offers comparatively good perfor- sive version of the Fibonacci example discussed above mance compared to RESTful Web APIs. on GitHub [10]. There you can find a variant where So there are many reasons to consider the combination the client sends requests for Fibonacci subsequences to of Go and gRPC especially in a cloud backend. gRPC is the server via stream and the server streams the results not a "REST killer" though. Outwardly to the web or back. mobile frontends one could use gRPC Web [12], but HTTP and JSON based web APIs (e.g. REST, GraphQL, Standard Interface Definitions JSON:API, OData) are often the better options in this If you try to implement a real API with gRPC, you will area. In my opinion, today's software development notice that you have to solve many problems that can world no longer consists of monocultures in which one be implemented with ProtoBuf, but where you would solution approach, one communication protocol, one have to invent basic interface definitions yourself. Ex- programming language or one framework must be the amples in this area are error codes and error messages, solution for everything. The right combination of tech- date values (ProtoBuf does not have a datatype built in nologies and tools is what counts. In my view, Go and for date values), monetary amounts with currencies, gRPC definitely have a place here. geocoordinates etc. Fortunately, Google provides the proto3 files on GitHub, which the company uses for its Rainer Stropek is an IT entrepreneur, software devel- own cloud APIs [11]. Since they are Open Source, they oper, trainer, author and lecturer in the Microsoft environment. He is MVP for Microsoft Azure since 2010 can be imported into your own projects. This way you and develops with his team time recording for service save the time it would take to reinvent the wheel. In ad- professional dition, consumers of the gRPC API find it easier to find their way around because they find structures they may already know from the Google APIs.

Conclusion Go is a good programming language for implementing microservices. The code is consistent, stable over a long time and easy to maintain. The ecosystem of open source libraries for cloud native microservices is excellent, as Go is at home in this area. The resulting executables are performant, compact, have no dependencies and are therefore particularly convenient to use in container and serverless environments. Microservices need a platform-independent interface to the outside world so that users are not forced Links & Literatur into a certain technological direction. Here gRPC is a good choice. The code generators that generate code [1] https://developers.google.com/protocol-buffers/docs/ from proto3 files are available for practically all com- proto3 [2] https://grpc.io/docs/tutorials/ [3] https://blog.golang.org/survey2018-results [4] https://github.com/protocolbuffers/protobuf/releases [5] https://github.com/grpc/grpc-go/blob/master/examples/ features/encryption/TLS/server/main.go FinTech + API First = GraphQL [6] https://godoc.org/google.golang.org/grpc#Server. Sebastian Galonska (Kontist GmbH) GracefulStop [7] https://github.com/grpc/grpc-go/blob/master/examples/ Three years ago we have started to features/authentication/server/main.go build a bank. We made some mistakes, [8] https://godoc.org/context one of them was our API. This talk [9] http://bit.ly/fibonacci-go describes our journey from an impro- vised anarchistic REST API to a well- [10] https://github.com/rstropek/Samples/tree/master/ documented, typed GraphQL interface. I will touch BeyondREST/BeyondREST/GoGrpcServer on technical and cultural aspects which you should [11] https://github.com/googleapis/googleapis/tree/master/ consider if you plan to step into our footsteps. google [12] https://github.com/grpc/grpc-web

www.apiconference.net 16 WHITEPAPER API Platforms & Software-as-a-Service

A centrally managed distributed Data Exchange Layer between information systems X-Road – The Free and Open Source Data Exchange Layer

X-Road is an open source data exchange layer solution that enables organizations to exchange information over the Internet. X-Road is a centrally managed distributed data exchange layer between information systems that provides a standardized and secure way to produce and consume services. X-Road ensures confidentiality, integrity and interoperability between data exchange parties.

by Petteri Kivimäki • digital signature of messages • logging X-Road is used nationwide in the Estonian public ad- • error handling. ministration and in the Suomi.fi Data Exchange Layer service. In addition, Iceland is currently implementing Trusted Network its own X-Road data exchange layer environment called The identity of each organization and technical entry Straumurinn. X-Road is released under the MIT license point (Security Server) is verified using certificates that and is available free of charge for any individual or or- are issued by a trusted Certification Authority (CA) ganization. Nordic Institute for Interoperability Solu- when an organization joins an X-Road ecosystem. The tions (NIIS) is responsible for the development of the identities are maintained centrally, but all the data is X-Road core and providing support and insights to the exchanged directly between a consumer and provider. X-Road community (Image 1). Message routing is based on organization and service X-Road implements a set of common features to sup- level identifiers that are mapped to physical network port and facilitate data exchange. X-Road provides the locations of the services by X-Road. All the evidence following features out of the box: regarding the data exchange is stored locally by the data exchange parties, and no third parties have access to • address management the data. Time-stamping and digital signature together • message routing guarantee non-repudiation of the data sent via X-Road • access rights management (Image 2). • organization level authentication An X-Road ecosystem is a community of organiza- • machine level authentication tions using the same instance of the X-Road software • transportation layer encryption for producing and consuming services. The owner of • time-stamping the ecosystem, the governing authority, controls who’s

www.apiconference.net 17 WHITEPAPER API Platforms & Software-as-a-Service

Image 1: X-Road components, roles and responsibilities. allowed to join the community, and the owner defines cess point to both local and cross-border data sources. regulations and practices that the ecosystem must fol- However, it must be noted that federation is not only low. The ecosystem may be nationwide, like in Esto- about technology as both legal and administrative nia and Finland, or it may be limited to organizations agreements are needed between the X-Road operators matching certain criteria, e.g. clients of a commercial and member organizations that exchange data (Image service provider. Technically, the X-Road software does 3). not set any limitations to the size of the ecosystem or to the member organizations. Producing and Consuming Services Two X-Road ecosystems can be joined together, fed- The use of X-Road requires that all the message ex- erated. Federation is a one to one relationship between change parties are members of an X-Road ecosystem two ecosystems. Members of the federated ecosystems and they have access to an X-Road entry point, Secu- can publish and consume services with each other as if rity Server, which is required for both producing and they were members of the same ecosystem. For exam- consuming services. The Security Server mediates ser- ple, Finland's and Estonia's data exchange layers are vice calls and service responses between information connected to one another which enables cross-border systems, and it encapsulates the security aspects of the data exchange between the countries. Federation pro- X-Road infrastructure: managing keys for signing and vides members of the federated ecosystems a single ac- authentication, sending messages over secure channel,

Image 2: X-Road architecture

www.apiconference.net 18 WHITEPAPER API Platforms & Software-as-a-Service

Image 3: X-Road federation – connection between two X-Road ecosystems. creating the proof value for messages with digital signa- X-Road logs contain all the messages processed by tures, time-stamping and logging. the Security Server. Each message is time-stamped and signed which makes it possible to verify the message content afterwards. By default, the logs are stored locally by the Security Server — external parties do not have access to them. Both data using services and data sources are iden- Mistakes to avoid while building tified using X-Road’s globally unique identifiers. The API Products identifiers contain information about the X-Road ecosystem, member organization and information system Rahul Dighe (PayPal) that is consuming or producing data via X-Road. The identifiers are used internally by X-Road for routing I have had the unique opportunity over messages between data using services and data sources. the past few years to work on multiple API initiatives and observe and learn A data using service does not need to know the net- from several seasoned API practition- work address of a data source — X-Road automatically ers. In the past we have heard leading maps the service identifier to the correct network ad- practitioners talk about: dress. • How we should follow an API First approach • Think of API-as-a-Product Own Your Data • Developers as your customers Built-in features provided by X-Road can also be used • Design First vs. Code First for managing access rights to data sources. Access rights • API Governance management is based on the X-Road service identifiers. However, I continue to notice time and again that the The key idea of X-Road is that each service provider overall Developer Experience when it comes to using owns its data and is responsible for managing access APIs continue to have gaps that are unaddressed. rights of its services. In other words, publishing a service Even after religiously following all of the best prac- to X-Road does not mean that the service is automati- tices, one still ends up with a poor API design and cally accessible to all X-Road member organizations. strategy. This talk aims to showcase learnings that I have gathered either building APIs or witnessing oth- Usually, access rights are granted on information sys- ers and what API practitioners need to do take their tem level — a service provider grants a specific informa- APIs to the next level. tion system access to a service. This approach provides a tight control, but it may also generate much administra-

www.apiconference.net 19 WHITEPAPER API Platforms & Software-as-a-Service

Image 4: X-Road compared to point-to-point integrations tive work if the number of service consumers is changing managed by a governing authority that controls who is frequently. allowed to join the ecosystem. In Estonia and Finland X-Road is an open source technology, and anyone has the ecosystems are open for all kind of organizations access to it for free of charge. An X-Road ecosystem is (public, private, non-profit etc.) and joining them is free. Joining an X-Road ecosystem does not require an organization specific Security Server as a Security Server can be shared between multiple organizations or provided as a service by a third party, e.g. a commercial service provider. The process that is required to join an ecosys- APIs and Cross-Border Data Ex- tem is more time consuming compared to implementing a direct point-to-point integration, but it is necessary for change in E-Government Context creating trust between the members of the ecosystem. In Petteri Kivimäki (Nordic Institute for addition, the process is required only when a new or- Interoperability Solutions (NIIS)) ganization joins the ecosystem or a new Security Server is registered (Image 4). X-Road is an open source, distributed data exchange layer solution that ena- X-Road Development bles organizations to exchange informa- NIIS is responsible for developing X-Road core tech- tion over the Internet. X-Road ensures nology, and welcomes everyone to submit source code confidentiality, integrity and interoperability between data exchange parties. X-Road is re- contributions, new ideas and enhancement requests released under the MIT open source license. X-Road is garding X-Road. The backlog is public — anyone can used nationwide in the Estonian data exchange layer access it, leave comments and submit enhancement X-tee and in the Suomi.fi Data Exchange Layer ser- requests through the X-Road Service Desk portal. Ac- vice in Finland. However, X-Road is not just for public cessing the backlog and service desk requires creating sector organisations – all kinds of organisations re- an account which can be done in few seconds using the gardless of size or type can use it. Two X-Road eco- signup form. systems can be joined together, federated. Federation enables easy and secure cross-border data exchange between countries using X-Road. Nordic Institute for Interoperability Solutions (NIIS) is an association founded jointly by Finland and Estonia. Its mission is to develop e-governance solutions, kicking off with X-Road. X-Road provides a solution to API management and its approach is quite different from other solutions on the market. In addition, the development model – two countries developing an open source solution that‘s used for implementing nationwide services in multiple countries – is quite unique even in global scale. The aim of the presentation is to discuss Petteri Kivimäki is the CTO of the Nordic Institute for X-Road as a platform, its cross-border data exchange Interoperability Solutions (NIIS). The NIIS is an asso- capabilities and its unique development model. ciation founded jointly by Finland and Estonia which mission is to develop e-governance solutions, kicking off with the X-Road technology.

www.apiconference.net 20 WHITEPAPER API Platforms & Software-as-a-Service

Rethinking APIs Regulation as a Service

The development of digital fintech, rapid technological progress and the constant flow of money across borders have made it essential for companies to offer their products and services internationally while complying with the strict data protection laws of the EU. In this article Khallai Taylor will explore the evolution of Regulation-as-a-Service using PSD2 as the example that can be applied to any financial regulatory directive that requires specialized licensing and/or oversight handed down by the regions financial regulatory body.

by Khallai Taylor ment Service Directive 2 (PSD2) in 2015. The purpose of the directive not only monitors and secures the flow of Financial Institutions are increasingly vigilant of per- payments through europe but it requires banks to open ceived external security risk yet frequently disregard up there data to fintechs who provide innovative solu- how there APIs are designed for security. With the con- tions using this data and collaborating with banks. In this stant change of regulation and the heavy fines involved article we will explore the evolution of Regulation-as-a- with non compliance. Organizations not only need to Service using PSD2 as the example that can be applied to ensure that they have appropriate licensure but that any financial regulatory directive that requires specialized there APIs at least meet secure programming criteria licensing and/or oversight handed down by the regions that are in line with global cybersecurity standards for financial regulatory body. Including international regula- secure APIs set forth by ISO. tory laws that apply to privacy like GDPR, investment Globally it is estimated that regulatory spending ex- banking such as MiFiD and Anti-Money Laundering. ceeds $ 80 billion per year and will surge to $120 billion Organizations participating in the business of pay- within the next 5 years. This is due to the increasing ment or remittances are subject to the consequences demand to secure customer information, data, and the of failing to meet financial regulatory requirements. In flow of money across international borders; Thereby, Germany BaFin ( Bundesanstalt für Finanzdienstleis- necessitating the need for enhanced and ongoing cyber- tungsaufsicht) the countries’ federal financial supervi- security protection. Regulatory bodies in Europe recog- sory authority regulates Banks, financial institutions nized this need and the increasing capabilities of bad and fintechs. As such they work in alignment with the actors to penetrate and manipulate data by using simple European Banking Authority, selective financial servic- measures to entice employees to make mistakes and/or es working groups and lobbyist to create regulations, circumvent company policies resulting in data breaches. provide standards and enforce the compliance of such Not to mention constant cyber attacks on financial or- regulation. With this comes a wide set of problems and ganizations and banking accounts of everyday people. ambiguity. Primary example being the implementation deadline of PSD2 that was initially set to take affect Sep. The evolution of Regulation-as-a-Service 14, 2019 within the EU. Due to the lack of a universal set The european union under the direction of the european of standards for PSD2 compliant APIs most banks were banking authority found it necessary to implement regu- unable to meet the looming deadline and requirements; lation that would identify and track the flow of money and in turn, blocked fintechs from accessing needed data within Europe, while enabling new forms of payment to sell their products to bank customers. In an effort to services to be offered. Resulting in the birth of the Pay- ensure that regulatory bodies like BaFin were aware of

www.apiconference.net 21 WHITEPAPER API Platforms & Software-as-a-Service

the conflict between the big banks and fintechs lobbyist In order to combat unintended cyber attacks regula- across the EU advocated for an extension to the imple- tors have worked to ensure security measures are inter- mentation deadline, clarity on suggested requirements twined into financial regulatory components that adhere to ensure that payment APi’s adhere to PSD2 strong to international cybersecurity standards. Such as requir- Customer Authentication criteria. ing strong customer authentication, the use of tokens In Germany some financial institutions are also third and use of electronic certificates that verify domains and party providers (fintechs) that have special licensure identities amongst other requirements set forth in the to offer payment initiation services and account infor- PSD2 directive. By understanding the value of data pri- mation services issued by BaFin. This licensure can be vacy many organizations are starting to realize that the passported to other companies allowing them to meet APIs they create must be done with a secure API mind- the regulatory requirements to provide payment ser- set. Ensuring that technologies used for Open Banking vices and handle customer account information. This and PSD2 are compliant thus safeguarding services of- coverage is extended to companies under the auspice of fered to EU citizens assuring not only product innova- Regulation-as-a-Service. Enabling companies to remain tion but secure APIs. innovative, agile and the ability to offer new products As mentioned earlier BaFin in partnership with the and services to customers while renting the required li- European Banking authority extended the PSD2 dead- cense to meet compliance standards. Saving the organi- line in Germany while allowing for fintechs to continue zation time and money while the fintech scales. to operate as normal while still remaining complaint. Unfortunately, some banks across the EU have found ways to circumvent PSD2’s primary initiative to share data with fintechs and have blocked fintechs from using Bank data. This is an ongoing fight in which the Eu- ropean Banking Authority and regulatory bodies are working to resolve within the EU. API Platform: a full-stack framework to build and consume Culminating in the rethinking of APIs. hypermedia and GraphQL APIs The evolution of fintechs, rapid technical advancement and the constant flow of money across borders has made in minutes it essential for organizations to provide their products Kévin Dunglas (Les-Tilleuls.coop) and services internationally while adhering to the strict privacy and data protection laws set forth by the EU. API Platform ( api-platform.com ) is Yet, many fintechs do not have the money nor time to a framework for building API-driven apply for specialized licensure from regulators. Thereby, projects that is becoming quite popular. these organizations are seeking alternative means to op- The server component enables users to create modern, extensible and secure erate while remaining compliant. Regulation-as-a-Ser- web APIs very easily: design the public data model vice allows fintechs the ability to innovate rapidly and you want to expose as a set of classes, and that’s partner with banks to offer new products to the market. all – you get a fully-featured API! Out of the box, the I predict that over the next three years Regulation -as-a- API will support most hypermedia formats (JSON-LD, Service will become common place within the industry Hydra, JSON:API, HAL…), will be documented using allowing companies to rapidly enter new markets. Due OpenAPI (v2 and v3) and can expose a GraphQL to Regulation-as-a-Service providers who incorporate endpoint. It also comes with a bunch of built-in filters, pagination, authentication, authorization, risk analysis, AI based compliance training and API HTTP/2 Server Push of the relations, nested docu- standardization and testing. Facilitating the expansion ments, deprecation and much more! It is able to use of services and offerings in the financial sector. In turn all popular DBMS, MongoDB, ElasticSearch, or your organizations will become diligent in securing APIs to custom system as a persistence layer.And because safeguard data and privacy of customers. Culminating API Platform is built on top of the popular and battle- in the rethinking of APIs. tested Symfony web framework, you can extend and override everything and benefit from thousands of high-quality plugins! But there’s more: API Platform also provides awesome client-side components (written in JavaScript) that work with the server component, or with any API supporting JSON-LD+Hydra! These components include a smart „admin“ builder (built on top of React Admin) and client generators Khallai Taylor (RegTheory) is a Fintech Product Evan- gelist in Berlin and a consultant of secure API’s and supporting React, Vue, React Native, Next, Quasar Blockchain in Africa, America, and Europe. Khallai works and Vuetify! Last but not least, API Platform comes directly with engineering, product, compliance and with the Docker images and Kubernetes chart you’ll sales teams ensuring streamlined communication and need to deploy in production, in seconds. product development between the teams. Khallai has 17+ years as a technologist, academic and an advocate for women in tech.

www.apiconference.net 22 WHITEPAPER API Management

Putting the API on the Acid Test Shopware 6 and the new API-First Approach

In this article on the Shopware 6 e-commerce platform, we look at the technical changes in the new version and the new API First approach.

by Thomas Eiling Shopware 6. The single page includes a functioning checkout with payment processing. The software basis for Shopware 6 is completely new The shop snippet is of interest to shop operators who and follows a rigorous API-first approach. The advan- blog a lot, work with influencers, etc. It allows you to in- tage of this compared to the previous version is that all tegrate products from a Shopware 6 shop in a blog post functionalities of the new administration can also be with a simple snippet, for example. There’s also a link managed via the API. By strictly following the API-first to the shop so you can buy there directly, of course. The approach, three different API endpoints have emerged: third experiment, the Alexa skill, connects the Shopware Sync, SalesChannel and Admin. The Sync endpoint is designed for importing and exporting large amounts of data, whereby 300 products per second can currently be imported. Lengthy processes, such as creating thumb- nails, are processed via a new messaging queue in the background. Asynchronous processing accelerates the import pro- Lessons Learned from cess significantly, of course, and allows us to achieve a Implementing API Management twenty-fold increase compared to Shopware 5. The Ad- in the Real World min API is systematically used by the new administra- Eldert Grootenboer (Motion10) tion, which is based on Vue.js. You can now use all the settings and functionalities that the admin offers via the API as well. This enables you to create custom interfaces Azure API Management is the gate- keeper to our data and processes, and for administrative tasks, such as a view for pending or- as such it’s really important that we set ders that need to be shipped. It doesn’t matter which it up securely. But how do we know technology is ultimately used for this purpose. Last but which features of API Management not least, there’s the SalesChannel API. This endpoint will allow us to reach our goal? And how should we is responsible for all requirements for connecting your implement them in such a way that we stay secure, own shop frontend, POS or any other sales channels, while still providing the best experience for our devel- enabling you to realise completely new sales concepts opers? This session will show you how to set up an API Management environment using real-life use on the Internet. We have published various experiments cases. You will learn how to expose and protect your on GitHub to show how simple it is to use the new API. services, which policies help make our life easier, and These consist of a one-page shop, a shop snippet and how to handle your application lifecycle manage- an Alexa skill. The one-page shop is an experiment that ment. shows how easy it is to build your own storefront for

www.apiconference.net 23 WHITEPAPER API Management

6 shop to Amazon’s Alexa. Once enabled, you can use Setting up a Demo Environment Alexa voice commands to search for products, order We use the Docker environment running on a Linux cli- them and have the product descriptions read aloud. ent. First, we clone the GitHub development template Furthermore, the status of an order can be tracked and using git clone [email protected]:shopware/development. new products suggested. These experiments are a good git. Now we have the development template for Shop- introduction to using and understanding the SalesChan- ware 6 in the development directory. We can now go nel API. into the directory using cd development and clone the Now let’s have a look at the Admin API. In the follow- actual Shopware platform repository into the standard ing sections, we will set up a demo environment; create, directory using git clone [email protected]:shopware/plat- update, delete a category; and see how to search for spe- form.git. Caution: Please do not specify any other direc- cific categories. tory when cloning, as this is important for autoloading. We now have all the source code we need to get started on the computer. To build and start the necessary Docker containers, we enter ./psh.phar docker:start. We Listing 1 then connect to the application container via ./psh.phar docker:ssh and start the installation with ./psh.phar in- $client = new GuzzleHttp\Client([ stall. 'base_uri' => 'http://localhost:8000', This may take quite a while the first time, because 'timeout' => 2.0, the initial execution requires several caches to be cre- 'headers' => ['Content-Type' => 'application/json'], ated. To check whether the installation was successful, ]); you can simply open your preferred browser and access http://localhost:8000. Mac users can also perform the $token = $client->post( set-up locally. You can find an example virtual host con- '/api/oauth/token', figuration in the Installation Guide under “Setting up [ your webserver”. All you have to do is execute bin/setup 'body' => json_encode([ and you will be guided through an interactive installa- 'client_id' => $clientId, 'client_secret' => $clientSecret, 'grant_type' => 'client_credentials', ]), ] ); OWASP Top 10 for API Inon Shkedy (OWASP)

Listing 2 Application security threats are evolv- $categories = $client->get( ing.Fortune 100 companies with large budgets and talented security '/api/v1/category/', engineers get breached through their [ APIs on a weekly basis. Uber full ac- 'headers' => [ count takeover, the famous Facebook breach, & the 'Authorization' => $token['token_type'] . ' ' . $token['access_token'], Verizon customer bills leakage are just a few recent 'Accept' => 'application/json', examples of API based breaches. Traditional vulner- ], abilities such as SQL injection, CSRF & XSS are less ]); prevalent thanks to modern technologies and security education. Attackers leverage the predictable and oversharing nature of REST APIs to exploit new types of vulnerabilities that are focused on business logic abuse and authorization. OWASP (the gold standard Listing 3 in AppSec) has acknowledged this shift in threats $result = $client->post( and has announced the OWASP API Security Project. The project addresses modern API threats and pro- '/api/v1/category?_response=true', vides mitigation techniques. [ Come learn from the leader of the project about: 'headers' => [...], • OWASP Top 10 For APIs and how they are differ- 'body' => json_encode(['name' => 'new Category']), ent from traditional top 10 lists. ] • Examples for complex API exploits, which involve ); many steps $result = json_decode((string) $result->getBody(), true); • How to exploit an API as a pentester, and how to $categoryIdentifier = $result['data']['_uniqueIdentifier']; protect it as a developer.

www.apiconference.net 24 WHITEPAPER API Management

tion process. If something doesn’t work during installa- name to new category updated. The whole thing is then tion, check if there’s a file called .psh.yaml.override. If sent as a PATCH request. The snippet now in use can be not, start the set-up script again with ./psh.phar install. found in Listing 4. Last but not least, we want to delete the newly created Using the Admin API category from the system. You can find the correspond- In the following examples, I use Guzzle 6. Other than ing source code snippet in Listing 5. that, I have no libraries in use. You can create the required client ID and client secret in the Administration Conclusion by going to SETTINGS | SYSTEM | INTEGRATIONS With its new API structure, Shopware offers shop opera- and clicking ADD INTEGRATION. We can now use tors, developers and agencies many new ways to estab- the client ID and client secret to generate a bearer to- lish their e-commerce presence. It has never been easier ken, which we will need for further API requests (Listing to connect third-party systems to Shopware, let alone 1). Apart from OAuth, all other routes are versioned to build your own storefronts in order to enable an even ensure backward compatibility with future changes to greater customer-specific approach. Despite all the new the API. You can tell by the v1 in the route name. At functions, there is no negative impact on performance. the moment, only Version 1 exists. We now have all the The current benchmarks for the API are already rather necessary information in $token to authorise ourselves promising and enable ERP integrations to implement for the next requests. If we want to output all existing new synchronisation concepts. categories, we can do so as in Listing 2. Further examples on how to define filters, searches, sorting or limits Thomas Eiling works in the enterprise team of shop- for this query can be found in the online documentation ware AG and has been developing with Shopware since the first version. In addition to the actual program- for Shopware 6. ming in the team, he is also happy to take on DevOps So how do we set up a new category? Ultimately, tasks. much of what we do is identical to the request in which we retrieve all existing categories. The headers are identical and the endpoint in question is only extended by ?_ response=true to receive a return from the API including the unique identifier generated. Furthermore, a POST request is issued instead of a GET request. In order to create a category named new category, we need the following source code snippet from Listing 3. We evaluate the return of the API in order to store the unique identifier of the category for further requests. To amend the Documentation is the most newly created category, we don’t have to change much important Part of Your API in the previous snippet. We replace ?_response=true Development & Management with the unique identifier of the category and change the Milecia McGregor (Flipped Coding)

One of the biggest complaints from Listing 4 developers that work with APIs is the lack of good documentation. The most $client->patch( common reason for this is that docu- '/api/v1/category/' . $categoryIdentifier, mentation is an afterthought for many [ API developers. API developers have to manage 'headers' => [...], their own deadlines, keep up with any architectural 'body' => json_encode(['name' => 'new Category updated']), updates, and make sure their code works as expected ] on top of many other things. So how is documentation more important than any of these things and ); when do you have the time to write it? In this talk, attendees will learn how to implement documentation in every aspect of their API development and management. We’ll cover the reasons why you need Listing 5 documentation in the development phase and how it translate to the management phase. Then we’ll go $client->delete( over several strategies to make documentation easier '/api/v1/category/' . $categoryIdentifier, for API developers to write and better for other de- [ velopers to use. This will highlight concerns like how 'headers' => [...], documentation helps with scaling, how it helps keep ] a cleaner codebase, and how it helps make an API ); more maintainable over time

www.apiconference.net 25 WHITEPAPER API Management

Taking executable specifications seriously APIs have Properties – find and test them!

Most approaches to testing test individual examples. This is often not enough to tease out rare but realistic edge cases. As a result, it takes a large number of individual tests to really be confident that our API is ready for deployment: This is a lot of work. What if we could generate test cases automatically?

by Dr. Michael Sperber module Interface = let add (cart: Interface) (count: int) (item: Item) = cart.Add count item Doing so leads to thinking about tests not in terms of let total (cart: Interface): Price = cart.Total () individual examples, but general properties, and from there to an approach called property-based testing or We also add a factory interface, creating a shopping-cart QuickCheck. QuickCheck generates tests from proper- implementation from a catalog assigning a price to each ties. It has its origins in functional programming and has item: been a crucial tool in eliminating bugs from many complex software projects. But QuickCheck does more than type Catalog = Map help find bugs: It encourages thinking about our API in terms of properties, and this style of thinking often type Factory = leads to interesting domain insights and architectural abstract member make: Catalog -> Interface improvements. Now, the types give us some information about what APIs and Specifications kinds of values are input and output to the various op- Consider the following API for a simple "smart" shop- erations, but not what those values actually are. How ping cart, written in F# [1]: could we obtain that information? We could look at the implementation, but that might be messy and complex type Interface = - databases and microservices might be involved. We abstract member Add: int -> Item -> unit could look at unit tests, which common development abstract member Total: unit -> Price methodologies produce as a matter of course. These might look as follows, assuming there is a factory for The first method, Add, takes an integer representing a shopping carts available as factory: count, and an item to be added to the cart, and returns nothing. (unit is used in F# similarly to void in other let test = languages.) The second method returns a total price for let cart1 = factory.make Map.empty all items in the cart. (That's why it's "smart" - it knows assertEquals (Interface.total cart1) (Price 0) the prices of the items in it.) let cart2 = factory.make (Map.ofList [Item "Milk", Price 100; Item "Egg", We add a convenience module with functions for call- Price 20]) ing the methods: assertEquals (Interface.total cart2) (Price 0)

www.apiconference.net 26 WHITEPAPER API Management

(We assume a function assertEquals from some test FsCheck provides a function called quick that checks frameworks, and that items and prices are constructed whether the property holds. In F# Interative, it prints with the Item and Price constructors.) output as follows: These are trivial tests, but they do make a point: The first one says that the total a freshly created shopping quick total0Correct;; cart is 0 - provided its catalog is empty. The second one Ok, passed 100 tests. says the same thing for a catalog containing only milk and eggs. The TDD community calls this an "execut- FsCheck has just generated 100 tests from the descrip- able specification" (or part of one), but there is still a lot tion of the property. We can instrument total0Correct missing. Looking at it, you might say "The total is 0 for to print out the catalogs of those tests: all shopping carts, for all possible catalogs." This is in fact a property of the shopping-cart factory, and, even map [(Item "HF", Price 1); (Item "dK", Price 2)] though may seem trivial, worth stating explicitly. This map [(Item "Bx", Price 1); (Item "QaY", Price 1); (Item "ca", Price 3)] could look as follows: map [(Item "Qhwu", Price 2); (Item "t", Price 3)] map [(Item "HS", Price 1); (Item "h", Price 3); (Item "uj", Price 1)] let total0Correct = map [(Item "IXVgqo", Price 1); (Item "Rgr", Price 5); (Item "Zgnh", Price 3)] Prop.forAll Arb.catalog (fun catalog -> map [(Item "ZXhwG", Price 4); (Item "nwFUSd", Price 2)] let cart = factory.make catalog ... Interface.total cart .=. Price 0) This means that FsCheck can generate many tests from a The Prop and Arb modules come from the FsCheck declarative description of a property. FsCheck's under- package. [2] Prop.forAll returns a property (of type lying idea comes from one of the most influential works Property) that should hold for all values from a certain in functional programming, the paper QuickCheck. [3] set. Arb.catalog means "arbitrary catalog", and Prop. The QuickCheck technique is so pervasively useful that forAll accepts a function for naming that catalog. The QuickCheck implementations exist for most program- body of that function is a boolean expression that first ming languages, even non-functional ones. creates a cart associated with the catalog, and then The total0Correct property shows two advantages checks whether the total reported by the cart is indeed over example-based unit tests like the two above: It 0. As opposed to the two "example unit tests" above, separates the general property from the specific exam- this states that the total is 0 for all catalogs. ples, thus being a more informative part of an executable specification. Moreover, generating many test cases from a single property is much more likely to find bugs in the code. Of course, total0Correct is quite simplistic. In Listing 1 is a more involved property. Again, this is a property that holds for all catalogs. For Flexible, hybrid API-led software each catalog, the property extracts the available items architectures with Kong from the catalog as items. It then goes on to say that the Sven Bernhardt property must also hold for all Arb.list (Arb.pickOneOf (OPITZ CONSULTING Deutschland GmbH) items). Translated to English, this means "an abitrary list of elements, each of which is picked from items" Kong is a lightweight, cloud-native API - or "an arbitrary list of items from the catalog". The solution that makes it easier and faster property then proceeds to construct a cart as before, and than ever to connect APIs and micro- uses List.iter to add one of each item to the catalog. The services in today’s hybrid, multi-cloud next line looks up the price for each item with the pro- environments. With its agnostic, flexible deployment approach, Kong can be used in today’s heterogeneous IT system landscapes to integrate a Listing 1 wide variety of data and systems – even across company boundaries – using APIs. In addition to REST let totalCorrect = APIs, Kong also offers support for gRPC and Graph- Prop.forAll Arb.catalog (fun catalog -> QL, which broadens the possibilities to implement let items = List.map fst (Map.toList catalog) modern application architectures. Prop.forAll (Arb.list (Arb.pickOneOf items)) (fun items -> In this presentation, we will discuss deployment patterns and use cases for Kong to demonstrate the let cart = factory.make catalog flexibility of the platform. Using a practical example, List.iter (Interface.add cart 1) items aspects of the API development and deployment let prices = List.map (Catalog.itemPrice catalog) items process as well as the integration in existing software let total = List.fold Price.add (Price 0) prices development processes will be discussed. Interface.total cart .=. total))

www.apiconference.net 27 WHITEPAPER API Management

vided Catalog.itemPrice function, calling the resulting Generating Test Data and Informing the Business list prices. The one ofter that uses Price.add to add all Consider extending the shopping cart with idea of a dis- those prices yielding total, and the last line compares count. Imagine the business requirement is that a dis- that total to the output of Interface.total. count can be described as "buy X, only pay for Y", with Y less than X. Such a discount could be described by the Finding Bugs following type alias: We can use the totalCorrect property to test a faulty implementation of the shopping-cart interface, producing type Discount = { receive: int; payFor: int } this output from FsCheck (Listing 2). This says that FsCheck found a counterexample that The available discounts could be described by a map as- proves that the property does not hold. The counterex- sociating an item with a discount: ample consists of a catalog from the first Prop.forAll and a list of items from the second Prop forAll - map type Discounts = Map [(Item "t", Price 4)] and [Item "t"; Item "t"], respec- tively. To take discounts into account, we add a method to the Thus, if the catalog contains just a single item called Factory interface: t priced at 4, adding that one t twice in a row results in a test failure. type Factory = But FsCheck does more. It shrinks the counterexam- abstract member make: Catalog -> Interface ple it found to create a simpler one, and comes up with abstract member make: Catalog * Discounts -> Interface one that has a simpler name (the empty string instead of t) and a simpler price (4 instead of 1). As this is the Now, imagine the business also requires that adding an simplest counterexample FsCheck could find, it means item to a shopping cart should never decrease the price. that just purchasing "one of the empty string" does not We can codify this requirement as a property as follows trigger the bug. This together with the statement Price (Listing 3). 1 = Price 2 gives a clue as to what the cause of the prob- There are now three nested Prop.forAll in the prop- lem is. In fact, when Interface.add is called twice for the erty: It must hold for all catalogs, but also for all dis- same item, it forgets about the first item. counts that are applicable for the catalog, and also any combination of counts and items already in the shopping cart before that one additional item is purchased. The subsequent lines prepare the shopping cart, calcu- Listing 2 late the total, add one item (for simplicity, it just uses quick totalCorrect;; the first item from the catalog), and calculate the total Falsifiable, after 2 tests (3 shrinks) (StdGen (957853183,296699855)): again, comparing them in the final line. Now, this prop- Label of failing property: Price 1 = Price 2 erty uses the custom function Arb.discounts to generate Original: discounts for a catalog. It is defined as follows: map [(Item "t", Price 4)] [Item "t"; Item "t"] let discounts catalog = Shrunk: let items = Seq.map fst (Map.toSeq catalog) map [(Item "", Price 1)] Arb.map (Arb.pickOneOf items) discount [Item ""; Item ""]

Listing 3 let addingItemIncreasesTotal = Keynote: Building Digital Prop.forAll Arb.catalog (fun catalog -> Ecosystems with APIs Prop.forAll (Arb.discounts catalog) (fun discounts -> Matthias Biehl ( API-University.com) Prop.forAll (Arb.countAndItems catalog) (fun countAndItems -> let cart = factory.make(catalog, discounts) List.iter (fun (count, item) -> Interface.add cart count item) Digital ecosystems offer personalised digital products to customers and new countAndItems opportunities for building competiti- let itemPrice = Seq.head (Map.toSeq catalog) ve advantage to companies. Digital let totalBefore = Interface.total cart ecosystems use APIs to tailor, integrate Interface.add cart 1 (fst itemPrice) and bundle the products of companies across indus- let totalAfter = Interface.total cart tries. This talk explores patterns for building digital totalAfter .>=. totalBefore))) ecosystems.

www.apiconference.net 28 WHITEPAPER API Management

This generates a map with the keys picked from the immediate benefit is increased coverage of tests, and items in the catalog, and the values generated as an arbi- thus less bugs. A more important consequence is in the trary discount. Here is its definition: properties themselves: Expressing and thinking about properties encourages thinking about the specification let discount = of the system under development. This leads to better let arbCount = Arb.choose 1 20 understanding of the business requirements, and fre- let convertTo (receive, payFor) = { receive = receive; payFor = payFor } quently to simpler and more elegant designs. let convertFrom discount = (discount.receive, discount.payFor) let valid (receive, payFor) = payFor < receive Dr. Michael Sperber is the managing director of Ac- Arb.convert convertTo convertFrom (Arb.filter valid (Arb.pair arbCount tive Group GmbH. He is an internationally recognized expert in functional programming. He has also written arbCount)) numerous specialist articles and books on the subject. Michael Sperber is the co-founder of the blog Funk- The key part here is the Arb.filter valid (Arb.pair arbN tionale-programmierung.de and co-organizer of the developer conference BOB. He is also one of the primary authors of the arbN) expression at the end: It says that a discount is iSAQB advanced curriculum "Functional Software Architecture". constructed from a pair of arbitrary counts, as long as that pair is valid. An arbitrary count arbCount is defined Links & Literatur in the first line as a integer between 1 und 20, and the valid function ensure the first business requirements - [1] https://github.com/active-group/apicon-2020 that customers always pay for less than they bought. [2] https://github.com/fscheck/FsCheck The convertTo and convertFrom functions merely convert between these pairs and the Discount type. [3] Koen Claessen, John Hughes: QuickCheck: A Lightweight Tool for Random Testing of Haskell Programs. International Conference on Functional Checking this property against a correct shopping- Programming, 2000. https://dl.acm.org/doi/10.1145/357766.351266 cart implementation shows a problem (Listing 4). The cause is apparent from the shrunk counterexam- [4] John Hughes: Experiences with QuickCheck: Testing the Hard Stuff and Staying Sane. A List of Successes That Can Change the World, pp. 169- ple. It comes with a catalog with a single item, which is 186. Springer, 2016. discounted as "buy 4, only pay for 1". If three items are already in the shopping cart (first, one was purchased, then two more), buying one more gets the cart over the threshold of 4 and decreases the price to 1. The insight from this is that, in "buy X, only pay for Y", really Y must be X-1 and cannot be less, which can be codified and communicated back to the business. This example again may be a bit simplistic, but dem- Taming the rising Complexity of onstrates the value of property-based testing for explor- Event-driven APIs ing the requirements and resulting specification, and Dr. Matthew O‘ Riordan (Ably Realtime) nailing down seemingly unlikely edge cases. Driven by consumer expectations and Conclusion the proliferation of IoT, by 2023 30 Properties and property-based testing are powerful ad- percent of all the world’s data will be ditions to the software developer's toolbox. The most consumed in real time – that’s 1.5 times the entire amount of data consumed today. Corresponding to this, by 2020, 50 percent of APIs will be event-driven. In this talk, I explore the Listing 4 often unforeseen complexities involved in both publi- quick (addingItemIncreasesTotal factory8);; shing and consuming event-driven APIs as adoption increases. Whilst initiatives like AsyncAPI are making Falsifiable, after 1 test (4 shrinks) (StdGen (1040086835,296699864)): significant progress in helping to define machine and Label of failing property: Price 1 >= Price 3 human readable specifications, developers still need Original: to think hard about which dimensions they want their map [(Item "uI", Price 2)] event-driven APIs to deliver on in the future, before map [(Item "uI", { receive = 4 they dive in. I will take you on a tour of different pro- payFor = 2 })] tocols that each address event-driven API challenges [(1, Item "uI"); (2, Item "uI")] with varying proficiency, diving into five key complexities: integrity vs. latency, throughput, push and pull Shrunk: subscriptions, downstream reliability and durability. map [(Item "", Price 1)] At the end of this talk I hope you will see that there map [(Item "", { receive = 4 is no silver bullet, but there are insights you can take payFor = 1 })] from real-world problems we’ve seen first-hand, and [(1, Item ""); (2, Item "")] apply that to the event-driven realtime APIs you are publishing or plan to publish soon.