license! Ralph Hamers, CEO and chairman Executive Board ING Group source: https://www.ing.com/Newsroom/All-news/We-want-to-be-a-tech-company-with-a-banking-license-Ralph-Hamers.htm
| Lead Architect of the API Platform • Jul 2012 – Aug 2016 • ING Belgium | SOA Architect • Jun 2012 – Apr 2013 • Eligible | Co-founder • Aug 2001 – Jun 2012 • SCA Package (DS Smith) | System Integration Coordinator … • Sep 1990 – Jun 1995 • University of Liège | Master of Physics Nordic API 2017 | A Journey from API Versioning to Canary Release https://youtu.be/Yke6Vut2Shc
| Lead Architect of the API Platform • Jul 2012 – Aug 2016 • ING Belgium | SOA Architect • Jun 2012 – Apr 2013 • Eligible | Co-founder • Aug 2001 – Jun 2012 • SCA Package (DS Smith) | System Integration Coordinator … • Sep 1990 – Jun 1995 • University of Liège | Master of Physics EDIFACT X12 SGML CORBA DCOM XML WS SOA ESB REST APIs
(e.g., numbers in the URL, HTTP headers, or response body) without much thought about the assumption behind that practice.” RESTful Web Clients by Mike Amundsen How?
(e.g., numbers in the URL, HTTP headers, or response body) without much thought about the assumption behind that practice.” RESTful Web Clients by Mike Amundsen How? @mamund
designers include versioning information (e.g., numbers in the URL, HTTP headers, or response body) without much thought about the assumption behind that practice.” RESTful Web Clients by Mike Amundsen
Handling change over time “Many API designers include versioning information (e.g., numbers in the URL, HTTP headers, or response body) without much thought about the assumption behind that practice.” RESTful Web Clients by Mike Amundsen
soon as they have a new brilliant idea want the APIs they are using to stay stable as long as they are not interested by the new brilliant ideas of the API Providers! API Consumers API Providers
to change their APIs as soon as they have a new brilliant idea want the APIs they are using to stay stable as long as they are not interested by the new brilliant ideas of the API Providers!
want to change their APIs as soon as they have a new brilliant idea want the APIs they are using to stay stable as long as they are not interested by the new brilliant ideas of the API Providers!
to change their APIs as soon as they have a new brilliant idea want the APIs they are using to stay stable as long as they are not interested by the new brilliant ideas of the API Providers!
endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 27 Meta-Model and Terminology for APIs Service API
endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 28 Meta-Model and Terminology for APIs Service API
endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 29 Meta-Model and Terminology for APIs API endpoint Service API
a common purpose. • API endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 30 Meta-Model and Terminology for APIs API endpoint Service API 1 0..n
a common purpose. • API endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 31 Meta-Model and Terminology for APIs API endpoint API specification Service API 1 0..n 1 1
a common purpose. • API endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 32 Meta-Model and Terminology for APIs API endpoint API specification Service API 1 0..n 1 1 1 1..n
a common purpose. • API endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 33 Meta-Model and Terminology for APIs API endpoint API specification Service API 1 0..n 1 1 1 1..n 1
a common purpose. • API endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 34 Meta-Model and Terminology for APIs API endpoint API specification Service Service version API 1 0..n 1 1 1 1..n 1 1 0..n
a common purpose. • API endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 35 Meta-Model and Terminology for APIs API endpoint API specification Service Service version Instance API 1 0..n 1 1 1 1..n 1 1 0..n 1 0..n
a common purpose. • API endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 36 Meta-Model and Terminology for APIs API endpoint API specification Service Service version Xs.Ys.Zs Instance API 1 0..n 1 1 1 1..n 1 1 0..n 1 0..n
a common purpose. • API endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 37 Meta-Model and Terminology for APIs API endpoint API specification Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API 1 0..n 1 1 1 1..n 1 1 0..n 1 0..n
Tom Preston-Werner, co- founder of GitHub – to format version numbers of software packages. You can find the full specification at http://semver.org/. Semantic Versioning for both API Specifications and Services 38
Tom Preston-Werner, co- founder of GitHub – to format version numbers of software packages. You can find the full specification at http://semver.org/. MAJOR.MINOR.PATCHor X.Y.Z where X, Y and Z are non-negative integers 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards-compatible manner, and 3. PATCH version when you make backwards-compatible bug fixes. Semantic Versioning for both API Specifications and Services 39
Tom Preston-Werner, co- founder of GitHub – to format version numbers of software packages. You can find the full specification at http://semver.org/. MAJOR.MINOR.PATCHor X.Y.Z where X, Y and Z are non-negative integers 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards-compatible manner, and 3. PATCH version when you make backwards-compatible bug fixes. Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it should be precise and comprehensive. Semantic Versioning for both API Specifications and Services 40
Tom Preston-Werner, co- founder of GitHub – to format version numbers of software packages. You can find the full specification at http://semver.org/. MAJOR.MINOR.PATCHor X.Y.Z where X, Y and Z are non-negative integers 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards-compatible manner, and 3. PATCH version when you make backwards-compatible bug fixes. Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it should be precise and comprehensive. Swagger/OpenAPI 2.0 specification – https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md Semantic Versioning for both API Specifications and Services 41
the Swagger/OpenAPI file MUST be incremented if changes that do not require any services implementing the API to be changed, are introduced. 11. Patch version Z(s) (x(s).y(s).Z(s) | x(s) > 0) of a service MUST be incremented if only backwards compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior and MUST NOT require any changes to the Swagger/OpenAPI file. The patch version Z(s) of a service MUST NOT be constrained by the patch version Z(a) of the Swagger/OpenAPI file, and vice-versa. 12. Minor version Y(a) (x(a).Y(a).z(a) | x(a) > 0) of the Swagger/OpenAPI file MUST be incremented if new, backwards compatible functionality is introduced to the API. It MUST be incremented if any API functionality is marked as deprecated. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented. 13. Minor version Y(s) (x(s).Y(s).z(s) | x(s) > 0) of a service MUST be incremented, together with the Swagger/OpenAPI file one, if new, backwards compatible functionality is introduced by the API changes. It MUST NOT be incremented if the minor version of the Swagger/OpenAPI file is not incremented. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented. The minor version Y(s) of a service MUST always be less than or equal to the minor version Y(a) of the Swagger/OpenAPI file, Y(s) ≤ Y(a). Semantic Versioning for both API Specifications and Services 42
the Swagger/OpenAPI file MUST be incremented if changes that do not require any services implementing the API to be changed, are introduced. 11. Patch version Z(s) (x(s).y(s).Z(s) | x(s) > 0) of a service MUST be incremented if only backwards compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior and MUST NOT require any changes to the Swagger/OpenAPI file. The patch version Z(s) of a service MUST NOT be constrained by the patch version Z(a) of the Swagger/OpenAPI file, and vice-versa. 12. Minor version Y(a) (x(a).Y(a).z(a) | x(a) > 0) of the Swagger/OpenAPI file MUST be incremented if new, backwards compatible functionality is introduced to the API. It MUST be incremented if any API functionality is marked as deprecated. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented. 13. Minor version Y(s) (x(s).Y(s).z(s) | x(s) > 0) of a service MUST be incremented, together with the Swagger/OpenAPI file one, if new, backwards compatible functionality is introduced by the API changes. It MUST NOT be incremented if the minor version of the Swagger/OpenAPI file is not incremented. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented. The minor version Y(s) of a service MUST always be less than or equal to the minor version Y(a) of the Swagger/OpenAPI file, Y(s) ≤ Y(a). Semantic Versioning for both API Specifications and Services 43
a common purpose. • API endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 44 Meta-Model and Terminology for APIs API endpoint API specification Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API 1 0..n 1 1 1 1..n 1 1 0..n 1 0..n
"/accounts" } API Service Discovery and Client-Side Load Balancing 75 Instance of Service~1 10.0.0.1:9001 API Service Discovery { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" }
“/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } API Service Discovery and Client-Side Load Balancing 78 Instance of Service~1 10.0.0.1:9001 API Service Discovery
“/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } API Service Discovery and Client-Side Load Balancing 79 Instance of Service~1 10.0.0.1:9001 Instance of Application~1 API Service Discovery
"urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } API Service Discovery and Client-Side Load Balancing 80 Instance of Service~1 10.0.0.1:9001 Instance of Application~1 API Service Discovery
"urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } API Service Discovery and Client-Side Load Balancing 85 Instance of Service~1 10.0.0.1:9001 Instance of Application~1 API Service Discovery
a common purpose. • API endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! • Service version is a version of a service. • Instance is a running process of a service version. As the running processes are addressable on TCP/IP network, you can call them via a socket identified by an IP address and a TCP port. 105 API Service Discovery and Client-Side Load Balancing API endpoint API specification Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API 1 0..n 1 1 1 1..n 1 1 0..n 1 0..n
a common purpose. • API endpoint is an interface; when using HTTP, an API endpoint is identified by the triplet {HTTP method, host, URL Path Template}. • API specification is a precise and comprehensive documentation of the API endpoints part of the API. We use the OpenAPI/Swagger standard. • Service is a piece of software, a piece of code, to be run in an out-of- process component, so it cannot be a library! 106 API Service Discovery and Client-Side Load Balancing API endpoint Service 1 1..n API 1 0..n 1
is a 1:1 mapping between a microservice instance and local load balancer (no central load balancer required!), which means every microservice can be configured and set up in exactly the same way using a default configuration that works for most services. In addition, the distributed architecture exhibits linear scale: each new microservice instance adds new load balancing capacity. Thus, the system is self-provisioning and automatically provides the capacity needed to handle the available instances of a service. Finally, by storing availability information locally with each load balancer instance, [Baker Street] ensures that all active microservice instances can still route traffic, even if some instances of the microservice or instances of [Baker Street] components. Source: https://thenewstack.io/baker-street-avoiding-bottlenecks-with-a-client-side-load-balancer-for-microservices/ API Service Discovery and Client-Side Load Balancing 135
Instance of Service~1 10.0.0.1:9001 Is this service allowed to implement this API endpoint? Is this application allowed to call this API endpoint? API Provider API Consumer API Registry
implementing which part of an API. We can implement this control by creating a structure making an explicit link between a service and a list of API endpoints part of an API. We will call such a structure our manifest. The Manifest 163 API endpoint API specification Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API Manifest
implementing which part of an API. We can implement this control by creating a structure making an explicit link between a service and a list of API endpoints part of an API. We will call such a structure our manifest. When we generate a manifest, we store/remember the version of the API specificationthat documents API endpoint at the moment the manifest is generated. The Manifest 164 API endpoint API specification Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API Manifest
"<paths/{path}/get|post|put|patch|delete from Swagger/OpenAPI>", "host": "<host from Swagger/OpenAPI>", "urlPathTemplate": "<paths/{path} from Swagger/OpenAPI>", "apiSpecificationVersion": "<info/version from Swagger/OpenAPI>" }, ... ] } The Manifest 165
it has first to declare its intention to do so. Subscription and Peer-Token 169 API endpoint API specification Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API
it has first to declare its intention to do so. We call subscription this relation between the software package, called an application, and a specific API endpoint. Subscription and Peer-Token 170 API endpoint API specification Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API Subscription Application
it has first to declare its intention to do so. We call subscription this relation between the software package, called an application, and a specific API endpoint. When we generate a peer-token, we store/remember the version of the API specification that documents the API endpoint at the moment the subscription is created. Subscription and Peer-Token 172 API endpoint API specification Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API (Subscription) Peer-Token Application
"<paths/{path}/get|post|put|patch|delete from Swagger/OpenAPI>", "host": "<host from Swagger/OpenAPI>", "urlPathTemplate": "<paths/{path} from Swagger/OpenAPI>", "apiSpecificationVersion": "<info/version from Swagger/OpenAPI>" }, ... ] } Subscription and Peer-Token 173
"<paths/{path}/get|post|put|patch|delete from Swagger/OpenAPI>", "host": "<host from Swagger/OpenAPI>", "urlPathTemplate": "<paths/{path} from Swagger/OpenAPI>", "apiSpecificationVersion": "<info/version from Swagger/OpenAPI>" }, ... ] } Subscription and Peer-Token 174 This is the exact same structure as the manifest ;-)
0..n 1 1 API Registry API Developer Portal Service 1 1..n Manifest Manifest Service version Xs.Ys.Zs 1 0..n API Provider Instance 1 0..n Instance of Service~1 10.0.0.1:9001
0..n 1 1 API Registry API Developer Portal Service 1 1..n Manifest Manifest Service version Xs.Ys.Zs 1 0..n API Provider Instance 1 0..n Instance of Service~1 10.0.0.1:9001
0..n 1 1 API Registry API Developer Portal Service 1 1..n Manifest Manifest Service version Xs.Ys.Zs 1 0..n API Provider Instance 1 0..n Instance of Service~1 10.0.0.1:9001 API Service Discovery
0..n 1 1 API Registry API Developer Portal Service 1 1..n Manifest Manifest Service version Xs.Ys.Zs 1 0..n API Provider Instance 1 0..n Instance of Service~1 10.0.0.1:9001 API Service Discovery Router Instance of Application~1 API Consumer
0..n 1 1 API Registry API Developer Portal Service 1 1..n Manifest Manifest Service version Xs.Ys.Zs 1 0..n API Provider Instance 1 0..n Instance of Service~1 10.0.0.1:9001 API Service Discovery Router Instance of Application~1 API Consumer
0..n 1 1 API Registry API Developer Portal Service 1 1..n Manifest Manifest Service version Xs.Ys.Zs 1 0..n API Provider Instance 1 0..n Instance of Service~1 10.0.0.1:9001 API Service Discovery Router Instance of Application~1 API Consumer Peer-Token (Subscription) Peer-Token Application
0..n 1 1 API Registry API Developer Portal Service 1 1..n Manifest Manifest Service version Xs.Ys.Zs 1 0..n API Provider Instance 1 0..n Instance of Service~1 10.0.0.1:9001 API Service Discovery Router Instance of Application~1 API Consumer Peer-Token (Subscription) Peer-Token Application
1 0..n 1 1 API Registry API Developer Portal Service 1 1..n Manifest Manifest Service version Xs.Ys.Zs 1 0..n API Provider Instance 1 0..n Instance of Service~1 10.0.0.1:9001 API Service Discovery Instance of Application~1 API Consumer Peer-Token (Subscription) Peer-Token Application API SDK
1 0..n 1 1 API Registry API Developer Portal Service 1 1..n Manifest Manifest Service version Xs.Ys.Zs 1 0..n API Provider Instance 1 0..n Instance of Service~1 10.0.0.1:9001 API Service Discovery Instance of Application~1 API Consumer Peer-Token (Subscription) Peer-Token Application API SDK SDK
version Xs.Ys.Zs Instance API 1 0..n 1 1 1 1..n 1 1 0..n 1 0..n Router Instance of Application~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 API Provider API Consumer API Registry API Developer Portal API SDK SDK Peer-Token Manifest (Subscription) Peer-Token Application Manifest
version Xs.Ys.Zs Instance API 1 0..n 1 1 1 1..n 1 1 0..n 1 0..n Router Instance of Application~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 API Provider API Consumer API Registry API Developer Portal API SDK SDK Peer-Token Manifest (Subscription) Peer-Token Application Manifest
version Xs.Ys.Zs Instance API 1 0..n 1 1 1 1..n 1 1 0..n 1 0..n Router Instance of Application~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 API Provider API Consumer API Registry API Developer Portal API SDK SDK Peer-Token Manifest (Subscription) Peer-Token Application Manifest
version Xs.Ys.Zs Instance API 1 0..n 1 1 1 1..n 1 1 0..n 1 0..n Router Instance of Application~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 API Provider API Consumer API Registry API Developer Portal API SDK SDK Peer-Token Manifest (Subscription) Peer-Token Application Manifest
of introducing a new software version in production by slowly rolling out the change to a small subset of users before making it available to everybody. Canary Release 203
of introducing a new software version in production by slowly rolling out the change to a small subset of users before making it available to everybody. The name for this technique originates from miners who would carry a canary in a cage down the coal mines. If toxic gases leaked into the mine, it would kill the canary before killing the miners. A canary release provides a similar form of early warning for potential problems before impacting your user base. Canary Release 204 Source: https://martinfowler.com/bliki/CanaryRelease.html
careful Application (API Specification x.Y.z) (Yes) API endpoint (API Specification x.Y.z) Application (API Specification x.Y.z) (Yes) API endpoint (API Specification x.Y+1.z) Application (API Specification x.Y+1.z) (Yes) API endpoint (API Specification x.Y+1.z) Application (API Specification x.Y+1.z) (No) API endpoint (API Specification x.Y.z) But, we can handle that by building the routing rules with information form both the API Registry and the API Service Discovery ;-) Routing 211
careful 1. Application (API Specification x.Y.z) (Yes) service (API Specification x.Y.z) Application (API Specification x.Y.z) (Yes) API endpoint (API Specification x.Y+1.z) Application (API Specification x.Y+1.z) (Yes) API endpoint (API Specification x.Y+1.z) Application (API Specification x.Y+1.z) (No) API endpoint (API Specification x.Y.z) But, we can handle that by building the routing rules with information form both the API Registry and the API Service Discovery ;-) Routing 212
careful 1. Application (API Specification x.Y.z) (Yes) service (API Specification x.Y.z) 2. Application (API Specification x.Y.z) (Yes) service (API Specification x.Y+1.z) Application (API Specification x.Y+1.z) (Yes) API endpoint (API Specification x.Y+1.z) Application (API Specification x.Y+1.z) (No) API endpoint (API Specification x.Y.z) But, we can handle that by building the routing rules with information form both the API Registry and the API Service Discovery ;-) Routing 213
careful 1. Application (API Specification x.Y.z) (Yes) service (API Specification x.Y.z) 2. Application (API Specification x.Y.z) (Yes) service (API Specification x.Y+1.z) 3. Application (API Specification x.Y+1.z) (Yes) service (API Specification x.Y+1.z) Application (API Specification x.Y+1.z) (No) API endpoint (API Specification x.Y.z) But, we can handle that by building the routing rules with information form both the API Registry and the API Service Discovery ;-) Routing 214
careful 1. Application (API Specification x.Y.z) (Yes) service (API Specification x.Y.z) 2. Application (API Specification x.Y.z) (Yes) service (API Specification x.Y+1.z) 3. Application (API Specification x.Y+1.z) (Yes) service (API Specification x.Y+1.z) 4. Application (API Specification x.Y+1.z) (No) service (API Specification x.Y.z) But, we can handle that by building the routing rules with information form both the API Registry and the API Service Discovery ;-) Routing 215
careful 1. Application (API Specification x.Y.z) (Yes) service (API Specification x.Y.z) 2. Application (API Specification x.Y.z) (Yes) service (API Specification x.Y+1.z) 3. Application (API Specification x.Y+1.z) (Yes) service (API Specification x.Y+1.z) 4. Application (API Specification x.Y+1.z) (No) service (API Specification x.Y.z) But, we can handle that by building the routing rules with information form both the API Registry and the API Service Discovery ;-) Routing 216
careful 1. Application (API Specification x.Y.z) (Yes) service (API Specification x.Y.z) 2. Application (API Specification x.Y.z) (Yes) service (API Specification x.Y+1.z) 3. Application (API Specification x.Y+1.z) (Yes) service (API Specification x.Y+1.z) 4. Application (API Specification x.Y+1.z) (No) service (API Specification x.Y.z) But, we can handle that by building the routing rules with information from both API Registry and API Service Discovery ;-) Routing 217
of Service~1 v1.0.5 Manifest 10.0.0.1:9001 API Service Discovery API SDK v1.1.0 Instance of Service~1 v1.1.2 10.0.0.2:9001 Manifest Application~2 (when v1.1.0) Subscription
• Use semantic versioning for both API specifications (OpenAPI/Swagger) and services • Make an explicit link between service and API endpoints within a manifest* Summary 267
• Use semantic versioning for both API specifications (OpenAPI/Swagger) and services • Make an explicit link between service and API endpoints within a manifest* • Register instances at run-time to API Service Discovery • Get the physical address of instances at run-time via API Service Discovery Summary 268
• Use semantic versioning for both API specifications (OpenAPI/Swagger) and services • Make an explicit link between service and API endpoints within a manifest* • Register instances at run-time to API Service Discovery • Get the physical address of instances at run-time via API Service Discovery • Request explicit subscriptions to API endpoints at design-time, and store them in API Registry • Make subscriptions available at run-time with peer-tokens* Summary 269
• Use semantic versioning for both API specifications (OpenAPI/Swagger) and services • Make an explicit link between service and API endpoints within a manifest* • Register instances at run-time to API Service Discovery • Get the physical address of instances at run-time via API Service Discovery • Request explicit subscriptions to API endpoints at design-time, and store them in API Registry • Make subscriptions available at run-time with peer-tokens* • Let the (client-side) router make a wise decision about which instance to call by combining information coming from API Registry and API Service Discovery * The structure of a manifest and a peer-token is the same – I like symmetry ;-) – and, for both, the trick is to remember/store the version of API specification ;-) Summary 270
• Use semantic versioning for both API specifications (OpenAPI/Swagger) and services • Make an explicit link between service and API endpoints within a manifest* • Register instances at run-time to API Service Discovery • Get the physical address of instances at run-time via API Service Discovery • Request explicit subscriptions to API endpoints at design-time, and store them in API Registry • Make subscriptions available at run-time with peer-tokens* • Let the (client-side) router make a wise decision about which instance to call by combining information coming from API Registry and API Service Discovery * The structure of a manifest and a peer-token is the same – I like symmetry ;-) – and, for both, the trick is to remember/store the version of API specification ;-) Summary 271
• Use semantic versioning for both API specifications (OpenAPI/Swagger) and services • Make an explicit link between service and API endpoints within a manifest* • Register instances at run-time to API Service Discovery • Get the physical address of instances at run-time via API Service Discovery • Request explicit subscriptions to API endpoints at design-time, and store them in API Registry • Make subscriptions available at run-time with peer-tokens* • Let the (client-side) router make a wise decision about which instance to call by combining information coming from API Registry and API Service Discovery * The structure of a manifest and a peer-token is the same – I like symmetry ;-) – and, for both, the trick is to remember/store the version of API specification ;-) • Extend this technique to other strategies for Canary Release, Confidence Check, A/B testing, … it’s a unified way to handle any special routing mechanisms you want to implement ;-) Summary 272
patrice1972
satoshi256kbyte
minodriven
sorah
hollycummins
timakin
kishida
htkym
iwiwi
optim
gonta
n_takehata
aleyda
caitiem20
gurzu
inesmontani
techseoconnect
greggifford
axbom
62gerente
jdejongh
hatefulcrawdad
sferik
![In particular, [Baker Street] creates a simpler management model: there](https://files.speakerdeck.com/presentations/ee797802172b4480b2b487af3d4b23ce/slide_134.jpg){kind=link}
