SlideShare a Scribd company logo

API Versioning for Zero Downtime | Devoxx Belgium 2017

•Download as PPTX, PDF•
•
Patrice Krakow
Patrice Krakow

API versioning is important to balance the needs of API providers who want to frequently update their APIs, and API consumers who want APIs to remain stable. API versioning allows both groups to work together by allowing providers to release new versions while maintaining backwards compatibility for consumers. It provides a standard way (Semantic Versioning) to increment version numbers based on the type of changes - major for incompatible changes, minor for backwards-compatible new features, and patch for backwards-compatible bug fixes. This allows consumers to control when they upgrade to a new version.

Software
1 of 277
API Versioning for Zero Downtime Patrice Krakow | ING | Lead Architect | APIs Devoxx Belgium 2017 Antwerp | 2017, November 8 (3.10.0)
ING 2
Why API? 3
PSD2 4 Why API?
PSD2 Payment Services Directive 2015/2366 source: https://ec.europa.eu/info/law/payment-services-psd-2-directive-eu- 2015-2366_en 5 Why API?
Why API? 6 ? ? ? ? Love brand
We want to be a tech company with a banking 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
ing.jobs/Belgium
ing.jobs/Belgium
Patrice Krakow 10 Nordic API 2017 | A Journey from API Versioning to Canary Release https://youtu.be/Yke6Vut2Shc
Patrice Krakow 11 • Sep 2016 – Present • ING | 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
Patrice Krakow 12 • Sep 2016 – Present • ING | 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
Why API Versioning? 13 “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 How?
Why API Versioning? 14 “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 How? @mamund
Why API Versioning? 15 2nd How?1st Why? “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
Why API Versioning? 16 2nd How?1st Why? Versioning = 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
Why API Versioning? 17
Why API Versioning? 18 API Consumers API Providers
Why API Versioning? 19 want to change their APIs as soon as they have a new brilliant idea API Consumers API Providers
Why API Versioning? 20 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! API Consumers API Providers
Why API Versioning? 21 What!? API Consumers 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!
Why API Versioning? 22 API Versionin g API Consumers 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!
Why API Versioning? 23 DON’ T API Consumers 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!
24 Why API Versioning?
25 Why API Versioning?
Meta-Model and Terminology for APIs 26
• API is a set of API endpoints. • 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. 27 Meta-Model and Terminology for APIs Service API
• API is a set of API endpoints. • 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
• API is a set of API endpoints. • 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
• API is a set of API endpoints that share 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
• API is a set of API endpoints that share 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
• API is a set of API endpoints that share 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
• API is a set of API endpoints that share 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
• API is a set of API endpoints that share 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
• API is a set of API endpoints that share 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
• API is a set of API endpoints that share 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
• API is a set of API endpoints that share 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
Semantic Versioning is a de-facto standard way – proposed by 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
Semantic Versioning is a de-facto standard way – proposed by 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.PATCH or 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
Semantic Versioning is a de-facto standard way – proposed by 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.PATCH or 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
Semantic Versioning is a de-facto standard way – proposed by 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.PATCH or 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
10. Patch version Z(a) (x(a).y(a).Z(a) | x(a) > 0) of 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
10. Patch version Z(a) (x(a).y(a).Z(a) | x(a) > 0) of 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
• API is a set of API endpoints that share 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
Our Journey to Zero Downtime 45
Our Journey to Zero Downtime 46 Meta-Model and Terminology for APIs
Our Journey to Zero Downtime 47 Meta-Model and Terminology for APIs API Gateway
Our Journey to Zero Downtime 48 Meta-Model and Terminology for APIs API Gateway API Service Discovery
Our Journey to Zero Downtime 49 Meta-Model and Terminology for APIs API Gateway API Service Discovery API Registry
Our Journey to Zero Downtime 50 Meta-Model and Terminology for APIs API Gateway API Service Discovery API Registry
Our Journey to Zero Downtime 51 Meta-Model and Terminology for APIs API Gateway API Service Discovery Routing API Registry
Our Journey to Zero Downtime 52 Meta-Model and Terminology for APIs API Gateway API Service Discovery Routing Canary Release API Registry
Our Journey to Zero Downtime 53 Meta-Model and Terminology for APIs Zero Downtime API Gateway API Service Discovery Routing Canary Release API Registry
Our Journey to Zero Downtime 54 Meta-Model and Terminology for APIs API Gateway API Service Discovery Routing Canary Release Zero Downtime API Registry
API Platform 55 API Gateway API Service Discovery API Registry
API Gateway 56
API Gateway 57 Outside Inside
API Gateway 58 Outside Inside
API Gateway 59 Outside Inside Office
API Gateway 60 Outside Inside Office
API Gateway 61 Outside Inside Office API Gateway on the external edge
API Gateway 62 Outside Inside Office API Gateway on the external edge API Gateway on the internal edge
API Service Discovery 63
API Service Discovery and Client-Side Load Balancing 64
API Service Discovery and Client-Side Load Balancing 65 API Service Discovery
API Service Discovery and Client-Side Load Balancing 66 API Service Discovery
API Service Discovery and Client-Side Load Balancing 67 API Service Discovery { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" }
API Service Discovery and Client-Side Load Balancing 68 Service~1 API Service Discovery { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" }
API Service Discovery and Client-Side Load Balancing 69 Instance of Service~1 10.0.0.1:9001 API Service Discovery { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" }
API Service Discovery and Client-Side Load Balancing 70 Instance of Service~1 10.0.0.1:9001 API Service Discovery { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" }
API Service Discovery and Client-Side Load Balancing 71
API Service Discovery and Client-Side Load Balancing 72 Instance of Service~1 10.0.0.1:9001 API Service Discovery { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" }
API Service Discovery and Client-Side Load Balancing 73 Instance of Service~1 10.0.0.1:9001 API Service Discovery { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" }
Logical Address Physical Address { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } API Service Discovery and Client-Side Load Balancing 74 Instance of Service~1 10.0.0.1:9001 API Service Discovery { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" }
Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/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" }
Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } API Service Discovery and Client-Side Load Balancing 76 { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } Instance of Service~1 10.0.0.1:9001 API Service Discovery
Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/accounts" } API Service Discovery and Client-Side Load Balancing 77 { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } Instance of Service~1 10.0.0.1:9001 API Service Discovery
Logical Address Physical Address { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/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
Logical Address Physical Address { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/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
Router Logical Address Physical Address { "method": “get", "host": “api.ing.com", "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
Router Logical Address Physical Address { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } API Service Discovery and Client-Side Load Balancing 81 Instance of Service~1 10.0.0.1:9001 Instance of Application~1 { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } API Service Discovery
Router Logical Address Physical Address { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } API Service Discovery and Client-Side Load Balancing 82 Instance of Service~1 10.0.0.1:9001 Instance of Application~1 { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } API Service Discovery
Router Logical Address Physical Address { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } API Service Discovery and Client-Side Load Balancing 83 Instance of Service~1 10.0.0.1:9001 Instance of Application~1 { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } API Service Discovery
Router Logical Address Physical Address { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } API Service Discovery and Client-Side Load Balancing 84 Instance of Service~1 10.0.0.1:9001 Instance of Application~1 { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } API Service Discovery
Router Logical Address Physical Address { "method": “get", "host": “api.ing.com", "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
Router Logical Address Physical Address { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } API Service Discovery and Client-Side Load Balancing 86 Instance of Service~1 10.0.0.1:9001 Instance of Application~1 Instance of Service~1 10.0.0.2:9001 API Service Discovery { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" }
Logical Address Physical Address { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.2:9001", "urlPathTemplate": “/accounts" } API Service Discovery and Client-Side Load Balancing 87 Router Instance of Service~1 Instance of Service~1 10.0.0.1:9001 10.0.0.2:9001 Instance of Application~1 API Service Discovery { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" }
Logical Address Physical Address { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.2:9001", "urlPathTemplate": “/accounts" } API Service Discovery and Client-Side Load Balancing 88 Router Instance of Service~1 Instance of Service~1 10.0.0.1:9001 10.0.0.2:9001 Instance of Application~1 API Service Discovery
Logical Address Physical Address { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.2:9001", "urlPathTemplate": “/accounts" } API Service Discovery and Client-Side Load Balancing 89 Router Instance of Service~1 10.0.0.2:9001 Instance of Application~1 { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } API Service Discovery Instance of Service~1 10.0.0.1:9001
Logical Address Physical Address { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.2:9001", "urlPathTemplate": “/accounts" } API Service Discovery and Client-Side Load Balancing 90 Router Instance of Service~1 10.0.0.2:9001 Instance of Application~1 { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } API Service Discovery Instance of Service~1 10.0.0.1:9001
Logical Address Physical Address { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.2:9001", "urlPathTemplate": “/accounts" } API Service Discovery and Client-Side Load Balancing 91 Router Instance of Service~1 10.0.0.2:9001 Instance of Application~1 { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } API Service Discovery Instance of Service~1 10.0.0.1:9001
Logical Address Physical Address { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.2:9001", "urlPathTemplate": “/accounts" } API Service Discovery and Client-Side Load Balancing 92 Router Instance of Service~1 10.0.0.2:9001 Instance of Application~1 { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } API Service Discovery Instance of Service~1 10.0.0.1:9001
Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/accounts" } { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.2:9001", "urlPathTemplate": "/accounts" } API Service Discovery and Client-Side Load Balancing 93 Router Instance of Service~1 10.0.0.2:9001 Instance of Application~1 { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } API Service Discovery Instance of Service~1 10.0.0.1:9001
Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/accounts" } { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.2:9001", "urlPathTemplate": "/accounts" } API Service Discovery and Client-Side Load Balancing 94
API Service Discovery and Client-Side Load Balancing 95 Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/accounts" } { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.2:9001", "urlPathTemplate": "/accounts" }
API Service Discovery and Client-Side Load Balancing 96 Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/accounts" } { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.2:9001", "urlPathTemplate": "/accounts" }
API Service Discovery and Client-Side Load Balancing 97 Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/accounts" } { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.2:9001", "urlPathTemplate": "/accounts" }
API Service Discovery and Client-Side Load Balancing 98 Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/accounts" } { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.2:9001", "urlPathTemplate": "/accounts" }
API Service Discovery and Client-Side Load Balancing 99 Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/accounts" } { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.2:9001", "urlPathTemplate": "/accounts" }
API Service Discovery and Client-Side Load Balancing 100 Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/accounts" } { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.2:9001", "urlPathTemplate": "/accounts" }
API Service Discovery and Client-Side Load Balancing 101 Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/accounts" } { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.2:9001", "urlPathTemplate": "/accounts" }
API Service Discovery and Client-Side Load Balancing 102 Why not DNS?
API Service Discovery and Client-Side Load Balancing 103
API Service Discovery and Client-Side Load Balancing 104
• API is a set of API endpoints that share 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
• API is a set of API endpoints that share 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
{ "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 107
{ "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 108
API Service Discovery and Client-Side Load Balancing 109 Service~2 Service~1 { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" }
API Service Discovery and Client-Side Load Balancing 110 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" }
API Service Discovery and Client-Side Load Balancing 111 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } Logical Address Physical Address { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } API Service Discovery
Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 112 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } API Service Discovery
Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payments" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 113 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } API Service Discovery
Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payments" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 114 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 API Service Discovery
Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payments" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 115 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 API Service Discovery Router Instance of Application~1
Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payments" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 116 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 API Service Discovery Router Instance of Application~1 { "method": "get", "host": “api.ing.com", "urlPathTemplate": “/payments" }
Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payments" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 117 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 API Service Discovery Router Instance of Application~1 { "method": "get", "host": “api.ing.com", "urlPathTemplate": “/payments" }
Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payments" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 118 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 API Service Discovery Router Instance of Application~1 { "method": "get", "host": “api.ing.com", "urlPathTemplate": “/payments" }
Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payments" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 119 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 API Service Discovery Router Instance of Application~1 { "method": "get", "host": “api.ing.com", "urlPathTemplate": “/payments" }
Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payments" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 120 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 API Service Discovery Router Instance of Application~1 { "method": "get", "host": “api.ing.com", "urlPathTemplate": “/payments" }
Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payments" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 121 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 API Service Discovery Router Instance of Application~1 { "method": "post", "host": “api.ing.com", "urlPathTemplate": “/payments" }
Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payments" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 122 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 API Service Discovery Router Instance of Application~1 { "method": "post", "host": “api.ing.com", "urlPathTemplate": “/payments" }
Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payments" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 123 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 API Service Discovery Router Instance of Application~1 { "method": "post", "host": “api.ing.com", "urlPathTemplate": “/payments" }
Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payments" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 124 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 API Service Discovery Router Instance of Application~1 { "method": "post", "host": “api.ing.com", "urlPathTemplate": “/payments" }
Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payments" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 125 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 API Service Discovery Router Instance of Application~1
Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payments" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 126
API Service Discovery and Client-Side Load Balancing 127 Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payment" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" }
API Service Discovery and Client-Side Load Balancing 128 Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payment" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" } DNS
API Service Discovery and Client-Side Load Balancing 129
API Service Discovery and Client-Side Load Balancing 130
Architect 131
Architect 132
API Service Discovery and Client-Side Load Balancing 133
API Service Discovery and Client-Side Load Balancing 134
In particular, [Baker Street] creates a simpler management model: there 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
API Registry 136
API Registry 137
API Registry 138 { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" }
API Registry 139 { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" }
API Registry 140 { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" }
API Registry 141 { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } Swagger 2.0
API Registry 142 { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } Swagger 2.0
API Registry 143 { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } Swagger 2.0 OpenAPI/Swagger 2.0
DON’T write “micro service”, but “microservice”! 144
DON’T mix “Open API” and “OpenAPI”! 145
API Registry 146 { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } Swagger 2.0 OpenAPI/Swagger 2.0
API Registry 147 { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } Swagger 2.0 OpenAPI/Swagger 2.0  OpenAPI 3.0
API Registry 148 { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } Swagger 2.0 OpenAPI/Swagger 2.0 https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md
API Registry 149 { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } swagger: '2.0' info: title: Account Information API version: 1.0.1 host: api.ing.com basePath: / schemes: - https consumes: - application/json produces: - application/json paths: /accounts: get: parameters: - ...
API Registry 150 { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } swagger: '2.0' info: title: Account Information API version: 1.0.1 host: api.ing.com basePath: / schemes: - https consumes: - application/json produces: - application/json paths: /accounts: get: parameters: - ... API Registry
API Registry 151 Router Instance of Service~1 10.0.0.1:9001 Instance of Application~1 API Service Discovery API Registry
API Registry 152 Router Instance of Application~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 API Registry
API Registry 153 Router Instance of Application~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 API Registry
API Registry 154 Router Instance of Application~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 API Provider API Registry
API Registry 155 Router Instance of Application~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 API ProviderAPI Consumer API Registry
API Registry 156 Router Instance of Application~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 API ProviderAPI Consumer API Registry
API Registry 157 Router Instance of Application~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 Is this service allowed to implement this API endpoint? API ProviderAPI Consumer API Registry
API Registry 158 Router Instance of Application~1 API Service Discovery 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 ProviderAPI Consumer API Registry
API Registry 159 Router Instance of Application~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 Manifest Is this application allowed to call this API endpoint? API Registry API ProviderAPI Consumer
API Registry 160 Router Instance of Application~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 Manifest Subscription API Registry API ProviderAPI Consumer
API Registry 161 Router Instance of Application~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 Manifest (Subscription) Peer-Token API Registry API ProviderAPI Consumer
Within our organization, we want to control which service is implementing which part of an API. The Manifest 162 API endpoint API specification Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API
Within our organization, we want to control which service is 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
Within our organization, we want to control which service is 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 specification that 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
{ "serviceName": "<Name of the Service>", "endpoints": [ { "method": "<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
{ "serviceName": "<Name of the Service>", "endpoints": [ { "method": "<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 166 Service~1 { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" }
{ "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": “1.0.1" }, ... ] } The Manifest 167 Service~1 { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } swagger: '2.0' info: title: Account Information API version: 1.0.1 host: api.ing.com basePath: / schemes: - https consumes: - application/json produces: - application/json paths: /accounts: get: parameters: - ...
Subscription and Peer-Token 168
When a software package wants to call an API endpoint, 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
When a software package wants to call an API endpoint, 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 SubscriptionApplication
Subscription and Peer-Token 171
When a software package wants to call an API endpoint, 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
{ “applicationName": "<Name of the Application>", "endpoints": [ { "method": "<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
{ “applicationName": "<Name of the Application>", "endpoints": [ { "method": "<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 ;-)
Subscription and Peer-Token 175
{ "applicationName": "Application~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.1" }, ... ] } Subscription and Peer-Token 176
API Platform 177 API Gateway API Service Discovery API Registry
API Platform 178 API endpoint
API Platform 179 API endpoint API specification Xa.Ya.Za API 1 0..n 1 1
API Platform 180 API endpoint API specification Xa.Ya.Za API 1 0..n 1 1 API Registry
API Platform 181 API endpoint API specification Xa.Ya.Za API 1 0..n 1 1 API Registry API Developer Portal
API Platform 182
API Platform 183 API endpoint API specification Xa.Ya.Za API 1 0..n 1 1 API Registry API Developer Portal
API Platform 184 API endpoint API specification Xa.Ya.Za API 1 0..n 1 1 API Registry API Developer Portal Service 1 1..n Service~1
API Platform 185 API endpoint API specification Xa.Ya.Za API 1 0..n 1 1 API Registry API Developer Portal Service 1 1..n Service~1 Manifest Manifest
API Platform 186 API endpoint API specification Xa.Ya.Za API 1 0..n 1 1 API Registry API Developer Portal Service 1 1..n Service~1 Manifest Manifest
API Platform 187 API endpoint API specification Xa.Ya.Za API 1 0..n 1 1 API Registry API Developer Portal Service 1 1..n Service~1 Manifest Manifest Service version Xs.Ys.Zs 1 0..n
API Platform 188 API endpoint API specification Xa.Ya.Za API 1 0..n 1 1 API Registry API Developer Portal Service 1 1..n Service~1 Manifest Manifest Service version Xs.Ys.Zs 1 0..n API Provider
API Platform 189 API endpoint API specification Xa.Ya.Za API 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 Platform 190 API endpoint API specification Xa.Ya.Za API 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 Platform 191 API endpoint API specification Xa.Ya.Za API 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
API Platform 192 API endpoint API specification Xa.Ya.Za API 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 Router Instance of Application~1 API Consumer
API Platform 193 API endpoint API specification Xa.Ya.Za API 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 Router Instance of Application~1 API Consumer
API Platform 194 API endpoint API specification Xa.Ya.Za API 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 Router Instance of Application~1 API Consumer Peer-Token (Subscription) Peer-Token Application
API Platform 195 API endpoint API specification Xa.Ya.Za API 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 Router Instance of Application~1 API Consumer Peer-Token (Subscription) Peer-Token Application
Router API Platform 196 API endpoint API specification Xa.Ya.Za API 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
Router API Platform 197 API endpoint API specification Xa.Ya.Za API 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
API Platform 198 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 Router Instance of Application~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 API ProviderAPI Consumer API Registry API Developer Portal API SDK SDK Peer-Token Manifest (Subscription) Peer-Token Application Manifest
Routing 199
Routing Conjecture 200 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 Router Instance of Application~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 API ProviderAPI Consumer API Registry API Developer Portal API SDK SDK Peer-Token Manifest (Subscription) Peer-Token Application Manifest
Routing Conjecture 201 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 Router Instance of Application~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 API ProviderAPI Consumer API Registry API Developer Portal API SDK SDK Peer-Token Manifest (Subscription) Peer-Token Application Manifest
Routing Conjecture 202 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 Router Instance of Application~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 API ProviderAPI Consumer API Registry API Developer Portal API SDK SDK Peer-Token Manifest (Subscription) Peer-Token Application Manifest
The canary release is a technique to reduce the risk 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
The canary release is a technique to reduce the risk 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
Canary Release 205 Application~1 Router Instance of Service~1 v1.0.0
Canary Release 206 Application~1 Router Instance of Service~1 v1.1.0 Instance of Service~1 v1.0.0
Canary Release 207 Application~1 Router Instance of Service~1 v1.1.0 Instance of Service~1 v1.0.0 100% 10% 90%
Canary Release 208 Application~1 Router Instance of Service~1 v1.1.0 Instance of Service~1 v1.0.0 100% 50% 50%
Canary Release 209 Application~1 Router Instance of Service~1 v1.1.0 Instance of Service~1 v1.0.0 100% 90% 10%
Canary Release 210 Application~1 Router Instance of Service~1 v1.1.0 Instance of Service~1 v1.0.0 100% 100%
We can now implement the Canary Release, but let’s be 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
We can now implement the Canary Release, but let’s be 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
We can now implement the Canary Release, but let’s be 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
We can now implement the Canary Release, but let’s be 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
We can now implement the Canary Release, but let’s be 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
We can now implement the Canary Release, but let’s be 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
We can now implement the Canary Release, but let’s be 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
Routing 218
Routing 219 { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" }
Routing 220 { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } v1.0.3
Routing 221 swagger: '2.0' info: title: Account Information API version: 1.0.3 host: api.ing.com basePath: / schemes: - https paths: /accounts: get: parameters: - ... { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } v1.0.3
Routing 222 API Registry swagger: '2.0' info: title: Account Information API version: 1.0.3 host: api.ing.com basePath: / schemes: - https paths: /accounts: get: parameters: - ... { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } v1.0.3
Routing 223 API Registry API Developer Portal swagger: '2.0' info: title: Account Information API version: 1.0.3 host: api.ing.com basePath: / schemes: - https paths: /accounts: get: parameters: - ... { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } v1.0.3
Routing 224 API Registry API Developer Portal v1.0.3 swagger: '2.0' info: title: Account Information API version: 1.0.3 host: api.ing.com basePath: / schemes: - https paths: /accounts: get: parameters: - ...
Routing 225 API Registry API Developer Portal Service~1v1.0.3 swagger: '2.0' info: title: Account Information API version: 1.0.3 host: api.ing.com basePath: / schemes: - https paths: /accounts: get: parameters: - ...
Routing 226 v1.0.3 API Registry API Developer Portal Service~1 Manifest { "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } swagger: '2.0' info: title: Account Information API version: 1.0.3 host: api.ing.com basePath: / schemes: - https paths: /accounts: get: parameters: - ...
Routing 227 v1.0.3 API Registry API Developer Portal Service~1 Manifest { "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] }
Routing 228 v1.0.3 API Registry API Developer Portal Service~1 Manifest { "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] }
Routing 229 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest 10.0.0.1:9001 { "serviceName": “Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] }
Routing 230 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest 10.0.0.1:9001 { "serviceName": “Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] }
Routing 231 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest { "serviceName": “Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } 10.0.0.1:9001 API Service Discovery
Routing 232 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest { "serviceName": “Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } 10.0.0.1:9001 API Service Discovery { "ip": "10.0.0.1:9001", "port": "9001" }
Routing 233 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest { "serviceName": “Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } 10.0.0.1:9001 API Service Discovery { "ip": "10.0.0.1:9001", "port": "9001", "manifest": { "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } }
Routing 234 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest 10.0.0.1:9001 API Service Discovery { "ip": "10.0.0.1:9001", "port": "9001", "manifest": { "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } }
{ "ip": "10.0.0.1:9001", "port": "9001", "manifest": { "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } } Routing 235 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest 10.0.0.1:9001 API Service Discovery
{ "ip": "10.0.0.1:9001", "port": "9001", "manifest": { "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } } Routing 236 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest 10.0.0.1:9001 API Service Discovery
{ "ip": "10.0.0.1:9001", "port": "9001", "manifest": { "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } } Routing 237 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest 10.0.0.1:9001 API Service Discovery Application~1
{ "ip": "10.0.0.1:9001", "port": "9001", "manifest": { "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } } Routing 238 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest 10.0.0.1:9001 API Service Discovery Application~1 (when v1.0.3) Subscription
{ "ip": "10.0.0.1:9001", "port": "9001", "manifest": { "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } } Routing 239 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest 10.0.0.1:9001 API Service Discovery Application~1 (when v1.0.3) Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] }
{ "ip": "10.0.0.1:9001", "port": "9001", "manifest": { "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } } Routing 240 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest 10.0.0.1:9001 API Service Discovery Instance of Application~1 (when v1.0.3) Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] }
Router { "ip": "10.0.0.1:9001", "port": "9001", "manifest": { "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } } Routing 241 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest 10.0.0.1:9001 API Service Discovery Instance of Application~1 (when v1.0.3) Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } API SDK
Router { "ip": "10.0.0.1:9001", "port": "9001", "manifest": { "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } } Routing 242 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest 10.0.0.1:9001 API Service Discovery Instance of Application~1 (when v1.0.3) Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } API SDK Peer-Token
Router { "ip": "10.0.0.1:9001", "port": "9001", "manifest": { "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } } Routing 243 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest 10.0.0.1:9001 API Service Discovery Instance of Application~1 (when v1.0.3) Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } API SDK Peer-Token
Router { "ip": "10.0.0.1:9001", "port": "9001", "manifest": { "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } } Routing 244 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest 10.0.0.1:9001 API Service Discovery Instance of Application~1 (when v1.0.3) Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } API SDK Peer-Token [ { "ip": "10.0.0.1", "port": "9001", "apiSpecificationVersion": "1.0.3" } ]
Router Routing 245 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest 10.0.0.1:9001 API Service Discovery Instance of Application~1 (when v1.0.3) Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } API SDK Peer-Token [ { "ip": "10.0.0.1", "port": "9001", "apiSpecificationVersion": "1.0.3" } ]
Router Routing 246 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest 10.0.0.1:9001 API Service Discovery Instance of Application~1 (when v1.0.3) Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } API SDK Peer-Token [ { "ip": "10.0.0.1", "port": "9001", "apiSpecificationVersion": "1.0.3" } ]
API Versioning for Zero Downtime | Devoxx Belgium 2017
API Versioning for Zero Downtime | Devoxx Belgium 2017
API Versioning for Zero Downtime | Devoxx Belgium 2017
API Versioning for Zero Downtime | Devoxx Belgium 2017
API Versioning for Zero Downtime | Devoxx Belgium 2017
API Versioning for Zero Downtime | Devoxx Belgium 2017
API Versioning for Zero Downtime | Devoxx Belgium 2017
API Versioning for Zero Downtime | Devoxx Belgium 2017
API Versioning for Zero Downtime | Devoxx Belgium 2017
API Versioning for Zero Downtime | Devoxx Belgium 2017
API Versioning for Zero Downtime | Devoxx Belgium 2017
API Versioning for Zero Downtime | Devoxx Belgium 2017
API Versioning for Zero Downtime | Devoxx Belgium 2017
API Versioning for Zero Downtime | Devoxx Belgium 2017
API Versioning for Zero Downtime | Devoxx Belgium 2017
API Versioning for Zero Downtime | Devoxx Belgium 2017
API Versioning for Zero Downtime | Devoxx Belgium 2017
API Versioning for Zero Downtime | Devoxx Belgium 2017
API Versioning for Zero Downtime | Devoxx Belgium 2017
API Versioning for Zero Downtime | Devoxx Belgium 2017
API Versioning for Zero Downtime | Devoxx Belgium 2017
API Versioning for Zero Downtime | Devoxx Belgium 2017
API Versioning for Zero Downtime | Devoxx Belgium 2017
API Versioning for Zero Downtime | Devoxx Belgium 2017
API Versioning for Zero Downtime | Devoxx Belgium 2017
API Versioning for Zero Downtime | Devoxx Belgium 2017
API Versioning for Zero Downtime | Devoxx Belgium 2017
API Versioning for Zero Downtime | Devoxx Belgium 2017
API Versioning for Zero Downtime | Devoxx Belgium 2017
API Versioning for Zero Downtime | Devoxx Belgium 2017
API Versioning for Zero Downtime | Devoxx Belgium 2017

Recommended

2.3.anypoint exchange
2.3.anypoint exchange2.3.anypoint exchange
2.3.anypoint exchange
Prakash Chakravarthi
 
Resume_Krishnendu_Ghosh
Resume_Krishnendu_GhoshResume_Krishnendu_Ghosh
Resume_Krishnendu_GhoshKrishnendu Ghosh
 
Atks (Arabic Toolkit services)
Atks (Arabic Toolkit services)Atks (Arabic Toolkit services)
Atks (Arabic Toolkit services)
faculty of computing and information system
 
Using the Java Client Library by Noah Crowley, DevRel | InfluxData
Using the Java Client Library by Noah Crowley, DevRel | InfluxDataUsing the Java Client Library by Noah Crowley, DevRel | InfluxData
Using the Java Client Library by Noah Crowley, DevRel | InfluxData
InfluxData
 
Build pipelines with TeamCity and Kotlin DSL
Build pipelines with TeamCity and Kotlin DSLBuild pipelines with TeamCity and Kotlin DSL
Build pipelines with TeamCity and Kotlin DSL
Anton Arhipov
 
INTERFACE by apidays_What's your Type? Understanding API Types and Choosing t...
INTERFACE by apidays_What's your Type? Understanding API Types and Choosing t...INTERFACE by apidays_What's your Type? Understanding API Types and Choosing t...
INTERFACE by apidays_What's your Type? Understanding API Types and Choosing t...
apidays
 
4 Major Advantages of API Testing
4 Major Advantages of API Testing4 Major Advantages of API Testing
4 Major Advantages of API Testing
QASource
 
Getting to Grips with RESTful APIs
Getting to Grips with RESTful APIsGetting to Grips with RESTful APIs
Getting to Grips with RESTful APIs
Petko Mikhailov
 

Recommended

2.3.anypoint exchange
2.3.anypoint exchange2.3.anypoint exchange
2.3.anypoint exchange
Prakash Chakravarthi
 
Resume_Krishnendu_Ghosh
Resume_Krishnendu_GhoshResume_Krishnendu_Ghosh
Resume_Krishnendu_GhoshKrishnendu Ghosh
 
Atks (Arabic Toolkit services)
Atks (Arabic Toolkit services)Atks (Arabic Toolkit services)
Atks (Arabic Toolkit services)
faculty of computing and information system
 
Using the Java Client Library by Noah Crowley, DevRel | InfluxData
Using the Java Client Library by Noah Crowley, DevRel | InfluxDataUsing the Java Client Library by Noah Crowley, DevRel | InfluxData
Using the Java Client Library by Noah Crowley, DevRel | InfluxData
InfluxData
 
Build pipelines with TeamCity and Kotlin DSL
Build pipelines with TeamCity and Kotlin DSLBuild pipelines with TeamCity and Kotlin DSL
Build pipelines with TeamCity and Kotlin DSL
Anton Arhipov
 
INTERFACE by apidays_What's your Type? Understanding API Types and Choosing t...
INTERFACE by apidays_What's your Type? Understanding API Types and Choosing t...INTERFACE by apidays_What's your Type? Understanding API Types and Choosing t...
INTERFACE by apidays_What's your Type? Understanding API Types and Choosing t...
apidays
 
4 Major Advantages of API Testing
4 Major Advantages of API Testing4 Major Advantages of API Testing
4 Major Advantages of API Testing
QASource
 
Getting to Grips with RESTful APIs
Getting to Grips with RESTful APIsGetting to Grips with RESTful APIs
Getting to Grips with RESTful APIs
Petko Mikhailov
 
Api testing
Api testingApi testing
Api testing
HamzaMajid13
 
Beautiful APIs - SOSE2021 Keynote
Beautiful APIs - SOSE2021 KeynoteBeautiful APIs - SOSE2021 Keynote
Beautiful APIs - SOSE2021 Keynote
Cesare Pautasso
 
Mocking APIs Collaboratively with Postman
Mocking APIs Collaboratively with PostmanMocking APIs Collaboratively with Postman
Mocking APIs Collaboratively with Postman
Nordic APIs
 
Community Tech Days C# 4.0
Community Tech Days C# 4.0Community Tech Days C# 4.0
Community Tech Days C# 4.0
SANKARSAN BOSE
 
apidays LIVE Australia 2020 - Have your cake and eat it too: GraphQL? REST? W...
apidays LIVE Australia 2020 - Have your cake and eat it too: GraphQL? REST? W...apidays LIVE Australia 2020 - Have your cake and eat it too: GraphQL? REST? W...
apidays LIVE Australia 2020 - Have your cake and eat it too: GraphQL? REST? W...
apidays
 
Api FUNdamentals #MHA2017
Api FUNdamentals #MHA2017Api FUNdamentals #MHA2017
Api FUNdamentals #MHA2017
JoEllen Carter
 
Lambda Behave - Java 8's Testing Framework
Lambda Behave - Java 8's Testing FrameworkLambda Behave - Java 8's Testing Framework
Lambda Behave - Java 8's Testing Framework
sara stanford
 
Tutorial for developing SILOptimizer Pass
Tutorial for developing SILOptimizer PassTutorial for developing SILOptimizer Pass
Tutorial for developing SILOptimizer Pass
秋 勇紀
 
Meetup #5 API Testing World
Meetup #5 API Testing WorldMeetup #5 API Testing World
Meetup #5 API Testing World
Malang QA Community
 
REST vs. GraphQL: Critical Look
REST vs. GraphQL: Critical LookREST vs. GraphQL: Critical Look
REST vs. GraphQL: Critical Look
Nordic APIs
 
Extend soa with api management spoug- Madrid
Extend soa with api management spoug- MadridExtend soa with api management spoug- Madrid
Extend soa with api management spoug- Madrid
Vinay Kumar
 
Data Driven API Testing: Best Practices for Real-World Testing Scenarios
Data Driven API Testing: Best Practices for Real-World Testing ScenariosData Driven API Testing: Best Practices for Real-World Testing Scenarios
Data Driven API Testing: Best Practices for Real-World Testing Scenarios
SmartBear
 
Beyond 49x Transformers: Don't be afraid of (the) Python!
Beyond 49x Transformers: Don't be afraid of (the) Python!Beyond 49x Transformers: Don't be afraid of (the) Python!
Beyond 49x Transformers: Don't be afraid of (the) Python!
Safe Software
 
Evaluating and Testing Web APIs
Evaluating and Testing Web APIsEvaluating and Testing Web APIs
Evaluating and Testing Web APIsSmartBear
 
API Testing: Answers to Your Top 3 Questions
API Testing: Answers to Your Top 3 QuestionsAPI Testing: Answers to Your Top 3 Questions
API Testing: Answers to Your Top 3 Questions
QASource
 
Tech Days 2015: Ada 2012 and Spark Crazyflie and Railway Demo
Tech Days 2015: Ada 2012 and Spark Crazyflie and Railway DemoTech Days 2015: Ada 2012 and Spark Crazyflie and Railway Demo
Tech Days 2015: Ada 2012 and Spark Crazyflie and Railway Demo
AdaCore
 
Speech to text software
Speech to text softwareSpeech to text software
Speech to text software
RDI Egypt
 
Raml part 1
Raml part 1Raml part 1
Raml part 1
venkata20k
 
A Journey from API Versioning to Canary Release | APIDays Zurich 2017
A Journey from API Versioning to Canary Release | APIDays Zurich 2017A Journey from API Versioning to Canary Release | APIDays Zurich 2017
A Journey from API Versioning to Canary Release | APIDays Zurich 2017
Patrice Krakow
 
A Journey from API Versioning to Canary Release | Nordic APIs Platform Summit...
A Journey from API Versioning to Canary Release | Nordic APIs Platform Summit...A Journey from API Versioning to Canary Release | Nordic APIs Platform Summit...
A Journey from API Versioning to Canary Release | Nordic APIs Platform Summit...
Patrice Krakow
 
API Documentation.pptx
API Documentation.pptxAPI Documentation.pptx
API Documentation.pptx
RahulCR31
 
API Documentation.pptx
API Documentation.pptxAPI Documentation.pptx
API Documentation.pptx
RahulCR31
 

More Related Content

What's hot

Api testing
Api testingApi testing
Api testing
HamzaMajid13
 
Beautiful APIs - SOSE2021 Keynote
Beautiful APIs - SOSE2021 KeynoteBeautiful APIs - SOSE2021 Keynote
Beautiful APIs - SOSE2021 Keynote
Cesare Pautasso
 
Mocking APIs Collaboratively with Postman
Mocking APIs Collaboratively with PostmanMocking APIs Collaboratively with Postman
Mocking APIs Collaboratively with Postman
Nordic APIs
 
Community Tech Days C# 4.0
Community Tech Days C# 4.0Community Tech Days C# 4.0
Community Tech Days C# 4.0
SANKARSAN BOSE
 
apidays LIVE Australia 2020 - Have your cake and eat it too: GraphQL? REST? W...
apidays LIVE Australia 2020 - Have your cake and eat it too: GraphQL? REST? W...apidays LIVE Australia 2020 - Have your cake and eat it too: GraphQL? REST? W...
apidays LIVE Australia 2020 - Have your cake and eat it too: GraphQL? REST? W...
apidays
 
Api FUNdamentals #MHA2017
Api FUNdamentals #MHA2017Api FUNdamentals #MHA2017
Api FUNdamentals #MHA2017
JoEllen Carter
 
Lambda Behave - Java 8's Testing Framework
Lambda Behave - Java 8's Testing FrameworkLambda Behave - Java 8's Testing Framework
Lambda Behave - Java 8's Testing Framework
sara stanford
 
Tutorial for developing SILOptimizer Pass
Tutorial for developing SILOptimizer PassTutorial for developing SILOptimizer Pass
Tutorial for developing SILOptimizer Pass
秋 勇紀
 
Meetup #5 API Testing World
Meetup #5 API Testing WorldMeetup #5 API Testing World
Meetup #5 API Testing World
Malang QA Community
 
REST vs. GraphQL: Critical Look
REST vs. GraphQL: Critical LookREST vs. GraphQL: Critical Look
REST vs. GraphQL: Critical Look
Nordic APIs
 
Extend soa with api management spoug- Madrid
Extend soa with api management spoug- MadridExtend soa with api management spoug- Madrid
Extend soa with api management spoug- Madrid
Vinay Kumar
 
Data Driven API Testing: Best Practices for Real-World Testing Scenarios
Data Driven API Testing: Best Practices for Real-World Testing ScenariosData Driven API Testing: Best Practices for Real-World Testing Scenarios
Data Driven API Testing: Best Practices for Real-World Testing Scenarios
SmartBear
 
Beyond 49x Transformers: Don't be afraid of (the) Python!
Beyond 49x Transformers: Don't be afraid of (the) Python!Beyond 49x Transformers: Don't be afraid of (the) Python!
Beyond 49x Transformers: Don't be afraid of (the) Python!
Safe Software
 
Evaluating and Testing Web APIs
Evaluating and Testing Web APIsEvaluating and Testing Web APIs
Evaluating and Testing Web APIsSmartBear
 
API Testing: Answers to Your Top 3 Questions
API Testing: Answers to Your Top 3 QuestionsAPI Testing: Answers to Your Top 3 Questions
API Testing: Answers to Your Top 3 Questions
QASource
 
Tech Days 2015: Ada 2012 and Spark Crazyflie and Railway Demo
Tech Days 2015: Ada 2012 and Spark Crazyflie and Railway DemoTech Days 2015: Ada 2012 and Spark Crazyflie and Railway Demo
Tech Days 2015: Ada 2012 and Spark Crazyflie and Railway Demo
AdaCore
 
Speech to text software
Speech to text softwareSpeech to text software
Speech to text software
RDI Egypt
 
Raml part 1
Raml part 1Raml part 1
Raml part 1
venkata20k
 

What's hot (18)

Api testing
Api testingApi testing
Api testing
 
Beautiful APIs - SOSE2021 Keynote
Beautiful APIs - SOSE2021 KeynoteBeautiful APIs - SOSE2021 Keynote
Beautiful APIs - SOSE2021 Keynote
 
Mocking APIs Collaboratively with Postman
Mocking APIs Collaboratively with PostmanMocking APIs Collaboratively with Postman
Mocking APIs Collaboratively with Postman
 
Community Tech Days C# 4.0
Community Tech Days C# 4.0Community Tech Days C# 4.0
Community Tech Days C# 4.0
 
apidays LIVE Australia 2020 - Have your cake and eat it too: GraphQL? REST? W...
apidays LIVE Australia 2020 - Have your cake and eat it too: GraphQL? REST? W...apidays LIVE Australia 2020 - Have your cake and eat it too: GraphQL? REST? W...
apidays LIVE Australia 2020 - Have your cake and eat it too: GraphQL? REST? W...
 
Api FUNdamentals #MHA2017
Api FUNdamentals #MHA2017Api FUNdamentals #MHA2017
Api FUNdamentals #MHA2017
 
Lambda Behave - Java 8's Testing Framework
Lambda Behave - Java 8's Testing FrameworkLambda Behave - Java 8's Testing Framework
Lambda Behave - Java 8's Testing Framework
 
Tutorial for developing SILOptimizer Pass
Tutorial for developing SILOptimizer PassTutorial for developing SILOptimizer Pass
Tutorial for developing SILOptimizer Pass
 
Meetup #5 API Testing World
Meetup #5 API Testing WorldMeetup #5 API Testing World
Meetup #5 API Testing World
 
REST vs. GraphQL: Critical Look
REST vs. GraphQL: Critical LookREST vs. GraphQL: Critical Look
REST vs. GraphQL: Critical Look
 
Extend soa with api management spoug- Madrid
Extend soa with api management spoug- MadridExtend soa with api management spoug- Madrid
Extend soa with api management spoug- Madrid
 
Data Driven API Testing: Best Practices for Real-World Testing Scenarios
Data Driven API Testing: Best Practices for Real-World Testing ScenariosData Driven API Testing: Best Practices for Real-World Testing Scenarios
Data Driven API Testing: Best Practices for Real-World Testing Scenarios
 
Beyond 49x Transformers: Don't be afraid of (the) Python!
Beyond 49x Transformers: Don't be afraid of (the) Python!Beyond 49x Transformers: Don't be afraid of (the) Python!
Beyond 49x Transformers: Don't be afraid of (the) Python!
 
Evaluating and Testing Web APIs
Evaluating and Testing Web APIsEvaluating and Testing Web APIs
Evaluating and Testing Web APIs
 
API Testing: Answers to Your Top 3 Questions
API Testing: Answers to Your Top 3 QuestionsAPI Testing: Answers to Your Top 3 Questions
API Testing: Answers to Your Top 3 Questions
 
Tech Days 2015: Ada 2012 and Spark Crazyflie and Railway Demo
Tech Days 2015: Ada 2012 and Spark Crazyflie and Railway DemoTech Days 2015: Ada 2012 and Spark Crazyflie and Railway Demo
Tech Days 2015: Ada 2012 and Spark Crazyflie and Railway Demo
 
Speech to text software
Speech to text softwareSpeech to text software
Speech to text software
 
Raml part 1
Raml part 1Raml part 1
Raml part 1
 

Similar to API Versioning for Zero Downtime | Devoxx Belgium 2017

A Journey from API Versioning to Canary Release | APIDays Zurich 2017
A Journey from API Versioning to Canary Release | APIDays Zurich 2017A Journey from API Versioning to Canary Release | APIDays Zurich 2017
A Journey from API Versioning to Canary Release | APIDays Zurich 2017
Patrice Krakow
 
A Journey from API Versioning to Canary Release | Nordic APIs Platform Summit...
A Journey from API Versioning to Canary Release | Nordic APIs Platform Summit...A Journey from API Versioning to Canary Release | Nordic APIs Platform Summit...
A Journey from API Versioning to Canary Release | Nordic APIs Platform Summit...
Patrice Krakow
 
API Documentation.pptx
API Documentation.pptxAPI Documentation.pptx
API Documentation.pptx
RahulCR31
 
API Documentation.pptx
API Documentation.pptxAPI Documentation.pptx
API Documentation.pptx
RahulCR31
 
Schema-First API Design
Schema-First API DesignSchema-First API Design
Schema-First API Design
Yos Riady
 
REST-API's for architects and managers
REST-API's for architects and managersREST-API's for architects and managers
REST-API's for architects and managers
Patrick Savalle
 
API Conference 2021
API Conference 2021API Conference 2021
API Conference 2021
José Haro Peralta
 
Api design part 1
Api design part 1Api design part 1
Api design part 1
Ibrahim Elsawaf
 
apidays LIVE Hong Kong 2021 - Multi-Protocol APIs at Scale in Adidas by Jesus...
apidays LIVE Hong Kong 2021 - Multi-Protocol APIs at Scale in Adidas by Jesus...apidays LIVE Hong Kong 2021 - Multi-Protocol APIs at Scale in Adidas by Jesus...
apidays LIVE Hong Kong 2021 - Multi-Protocol APIs at Scale in Adidas by Jesus...
apidays
 
mulesoft birmingham meetup_api_designing_with_raml
mulesoft birmingham meetup_api_designing_with_ramlmulesoft birmingham meetup_api_designing_with_raml
mulesoft birmingham meetup_api_designing_with_raml
mohammadsakifuddin
 
Practices and tools for building better APIs
Practices and tools for building better APIsPractices and tools for building better APIs
Practices and tools for building better APIsNLJUG
 
Practices and tools for building better API (JFall 2013)
Practices and tools for building better API (JFall 2013)Practices and tools for building better API (JFall 2013)
Practices and tools for building better API (JFall 2013)
Peter Hendriks
 
RefCard API Architecture Strategy
RefCard API Architecture StrategyRefCard API Architecture Strategy
RefCard API Architecture Strategy
OCTO Technology
 
Apicurio Registry: Event-driven APIs & Schema governance for Apache Kafka | F...
Apicurio Registry: Event-driven APIs & Schema governance for Apache Kafka | F...Apicurio Registry: Event-driven APIs & Schema governance for Apache Kafka | F...
Apicurio Registry: Event-driven APIs & Schema governance for Apache Kafka | F...
HostedbyConfluent
 
Extend soa with api management Sangam18
Extend soa with api management Sangam18Extend soa with api management Sangam18
Extend soa with api management Sangam18
Vinay Kumar
 
APIdays Paris 2014 - Workshop - Craft and Deploy Your API in a Few Clicks Wit...
APIdays Paris 2014 - Workshop - Craft and Deploy Your API in a Few Clicks Wit...APIdays Paris 2014 - Workshop - Craft and Deploy Your API in a Few Clicks Wit...
APIdays Paris 2014 - Workshop - Craft and Deploy Your API in a Few Clicks Wit...
Restlet
 
How to design effective APIs
How to design effective APIsHow to design effective APIs
How to design effective APIs
Bansilal Haudakari
 
Highlights of WSO2 API Manager 4.0.0
Highlights of WSO2 API Manager 4.0.0Highlights of WSO2 API Manager 4.0.0
Highlights of WSO2 API Manager 4.0.0
WSO2
 
Gateway APIs, Envoy Gateway, and API Gateways
Gateway APIs, Envoy Gateway, and API GatewaysGateway APIs, Envoy Gateway, and API Gateways
Gateway APIs, Envoy Gateway, and API Gateways
Matt Turner
 
Best practices and advantages of REST APIs
Best practices and advantages of REST APIsBest practices and advantages of REST APIs
Best practices and advantages of REST APIs
Aparna Sharma
 

Similar to API Versioning for Zero Downtime | Devoxx Belgium 2017 (20)

A Journey from API Versioning to Canary Release | APIDays Zurich 2017
A Journey from API Versioning to Canary Release | APIDays Zurich 2017A Journey from API Versioning to Canary Release | APIDays Zurich 2017
A Journey from API Versioning to Canary Release | APIDays Zurich 2017
 
A Journey from API Versioning to Canary Release | Nordic APIs Platform Summit...
A Journey from API Versioning to Canary Release | Nordic APIs Platform Summit...A Journey from API Versioning to Canary Release | Nordic APIs Platform Summit...
A Journey from API Versioning to Canary Release | Nordic APIs Platform Summit...
 
API Documentation.pptx
API Documentation.pptxAPI Documentation.pptx
API Documentation.pptx
 
API Documentation.pptx
API Documentation.pptxAPI Documentation.pptx
API Documentation.pptx
 
Schema-First API Design
Schema-First API DesignSchema-First API Design
Schema-First API Design
 
REST-API's for architects and managers
REST-API's for architects and managersREST-API's for architects and managers
REST-API's for architects and managers
 
API Conference 2021
API Conference 2021API Conference 2021
API Conference 2021
 
Api design part 1
Api design part 1Api design part 1
Api design part 1
 
apidays LIVE Hong Kong 2021 - Multi-Protocol APIs at Scale in Adidas by Jesus...
apidays LIVE Hong Kong 2021 - Multi-Protocol APIs at Scale in Adidas by Jesus...apidays LIVE Hong Kong 2021 - Multi-Protocol APIs at Scale in Adidas by Jesus...
apidays LIVE Hong Kong 2021 - Multi-Protocol APIs at Scale in Adidas by Jesus...
 
mulesoft birmingham meetup_api_designing_with_raml
mulesoft birmingham meetup_api_designing_with_ramlmulesoft birmingham meetup_api_designing_with_raml
mulesoft birmingham meetup_api_designing_with_raml
 
Practices and tools for building better APIs
Practices and tools for building better APIsPractices and tools for building better APIs
Practices and tools for building better APIs
 
Practices and tools for building better API (JFall 2013)
Practices and tools for building better API (JFall 2013)Practices and tools for building better API (JFall 2013)
Practices and tools for building better API (JFall 2013)
 
RefCard API Architecture Strategy
RefCard API Architecture StrategyRefCard API Architecture Strategy
RefCard API Architecture Strategy
 
Apicurio Registry: Event-driven APIs & Schema governance for Apache Kafka | F...
Apicurio Registry: Event-driven APIs & Schema governance for Apache Kafka | F...Apicurio Registry: Event-driven APIs & Schema governance for Apache Kafka | F...
Apicurio Registry: Event-driven APIs & Schema governance for Apache Kafka | F...
 
Extend soa with api management Sangam18
Extend soa with api management Sangam18Extend soa with api management Sangam18
Extend soa with api management Sangam18
 
APIdays Paris 2014 - Workshop - Craft and Deploy Your API in a Few Clicks Wit...
APIdays Paris 2014 - Workshop - Craft and Deploy Your API in a Few Clicks Wit...APIdays Paris 2014 - Workshop - Craft and Deploy Your API in a Few Clicks Wit...
APIdays Paris 2014 - Workshop - Craft and Deploy Your API in a Few Clicks Wit...
 
How to design effective APIs
How to design effective APIsHow to design effective APIs
How to design effective APIs
 
Highlights of WSO2 API Manager 4.0.0
Highlights of WSO2 API Manager 4.0.0Highlights of WSO2 API Manager 4.0.0
Highlights of WSO2 API Manager 4.0.0
 
Gateway APIs, Envoy Gateway, and API Gateways
Gateway APIs, Envoy Gateway, and API GatewaysGateway APIs, Envoy Gateway, and API Gateways
Gateway APIs, Envoy Gateway, and API Gateways
 
Best practices and advantages of REST APIs
Best practices and advantages of REST APIsBest practices and advantages of REST APIs
Best practices and advantages of REST APIs
 

Recently uploaded

Gamify Your Mind; The Secret Sauce to Delivering Success, Continuously Improv...
Gamify Your Mind; The Secret Sauce to Delivering Success, Continuously Improv...Gamify Your Mind; The Secret Sauce to Delivering Success, Continuously Improv...
Gamify Your Mind; The Secret Sauce to Delivering Success, Continuously Improv...
Shahin Sheidaei
 
AI Pilot Review: The World’s First Virtual Assistant Marketing Suite
AI Pilot Review: The World’s First Virtual Assistant Marketing SuiteAI Pilot Review: The World’s First Virtual Assistant Marketing Suite
AI Pilot Review: The World’s First Virtual Assistant Marketing Suite
Google
 
Large Language Models and the End of Programming
Large Language Models and the End of ProgrammingLarge Language Models and the End of Programming
Large Language Models and the End of Programming
Matt Welsh
 
Introduction to Pygame (Lecture 7 Python Game Development)
Introduction to Pygame (Lecture 7 Python Game Development)Introduction to Pygame (Lecture 7 Python Game Development)
Introduction to Pygame (Lecture 7 Python Game Development)
abdulrafaychaudhry
 
Text-Summarization-of-Breaking-News-Using-Fine-tuning-BART-Model.pptx
Text-Summarization-of-Breaking-News-Using-Fine-tuning-BART-Model.pptxText-Summarization-of-Breaking-News-Using-Fine-tuning-BART-Model.pptx
Text-Summarization-of-Breaking-News-Using-Fine-tuning-BART-Model.pptx
ShamsuddeenMuhammadA
 
How Recreation Management Software Can Streamline Your Operations.pptx
How Recreation Management Software Can Streamline Your Operations.pptxHow Recreation Management Software Can Streamline Your Operations.pptx
How Recreation Management Software Can Streamline Your Operations.pptx
wottaspaceseo
 
Cyaniclab : Software Development Agency Portfolio.pdf
Cyaniclab : Software Development Agency Portfolio.pdfCyaniclab : Software Development Agency Portfolio.pdf
Cyaniclab : Software Development Agency Portfolio.pdf
Cyanic lab
 
Developing Distributed High-performance Computing Capabilities of an Open Sci...
Developing Distributed High-performance Computing Capabilities of an Open Sci...Developing Distributed High-performance Computing Capabilities of an Open Sci...
Developing Distributed High-performance Computing Capabilities of an Open Sci...
Globus
 
Top Features to Include in Your Winzo Clone App for Business Growth (4).pptx
Top Features to Include in Your Winzo Clone App for Business Growth (4).pptxTop Features to Include in Your Winzo Clone App for Business Growth (4).pptx
Top Features to Include in Your Winzo Clone App for Business Growth (4).pptx
rickgrimesss22
 
Quarkus Hidden and Forbidden Extensions
Quarkus Hidden and Forbidden ExtensionsQuarkus Hidden and Forbidden Extensions
Quarkus Hidden and Forbidden Extensions
Max Andersen
 
A Sighting of filterA in Typelevel Rite of Passage
A Sighting of filterA in Typelevel Rite of PassageA Sighting of filterA in Typelevel Rite of Passage
A Sighting of filterA in Typelevel Rite of Passage
Philip Schwarz
 
Understanding Globus Data Transfers with NetSage
Understanding Globus Data Transfers with NetSageUnderstanding Globus Data Transfers with NetSage
Understanding Globus Data Transfers with NetSage
Globus
 
Utilocate provides Smarter, Better, Faster, Safer Locate Ticket Management
Utilocate provides Smarter, Better, Faster, Safer Locate Ticket ManagementUtilocate provides Smarter, Better, Faster, Safer Locate Ticket Management
Utilocate provides Smarter, Better, Faster, Safer Locate Ticket Management
Utilocate
 
Lecture 1 Introduction to games development
Lecture 1 Introduction to games developmentLecture 1 Introduction to games development
Lecture 1 Introduction to games development
abdulrafaychaudhry
 
Vitthal Shirke Java Microservices Resume.pdf
Vitthal Shirke Java Microservices Resume.pdfVitthal Shirke Java Microservices Resume.pdf
Vitthal Shirke Java Microservices Resume.pdf
Vitthal Shirke
 
Top 7 Unique WhatsApp API Benefits | Saudi Arabia
Top 7 Unique WhatsApp API Benefits | Saudi ArabiaTop 7 Unique WhatsApp API Benefits | Saudi Arabia
Top 7 Unique WhatsApp API Benefits | Saudi Arabia
Yara Milbes
 
Climate Science Flows: Enabling Petabyte-Scale Climate Analysis with the Eart...
Climate Science Flows: Enabling Petabyte-Scale Climate Analysis with the Eart...Climate Science Flows: Enabling Petabyte-Scale Climate Analysis with the Eart...
Climate Science Flows: Enabling Petabyte-Scale Climate Analysis with the Eart...
Globus
 
Field Employee Tracking System| MiTrack App| Best Employee Tracking Solution|...
Field Employee Tracking System| MiTrack App| Best Employee Tracking Solution|...Field Employee Tracking System| MiTrack App| Best Employee Tracking Solution|...
Field Employee Tracking System| MiTrack App| Best Employee Tracking Solution|...
informapgpstrackings
 
In 2015, I used to write extensions for Joomla, WordPress, phpBB3, etc and I ...
In 2015, I used to write extensions for Joomla, WordPress, phpBB3, etc and I ...In 2015, I used to write extensions for Joomla, WordPress, phpBB3, etc and I ...
In 2015, I used to write extensions for Joomla, WordPress, phpBB3, etc and I ...
Juraj Vysvader
 
May Marketo Masterclass, London MUG May 22 2024.pdf
May Marketo Masterclass, London MUG May 22 2024.pdfMay Marketo Masterclass, London MUG May 22 2024.pdf
May Marketo Masterclass, London MUG May 22 2024.pdf
Adele Miller
 

Recently uploaded (20)

Gamify Your Mind; The Secret Sauce to Delivering Success, Continuously Improv...
Gamify Your Mind; The Secret Sauce to Delivering Success, Continuously Improv...Gamify Your Mind; The Secret Sauce to Delivering Success, Continuously Improv...
Gamify Your Mind; The Secret Sauce to Delivering Success, Continuously Improv...
 
AI Pilot Review: The World’s First Virtual Assistant Marketing Suite
AI Pilot Review: The World’s First Virtual Assistant Marketing SuiteAI Pilot Review: The World’s First Virtual Assistant Marketing Suite
AI Pilot Review: The World’s First Virtual Assistant Marketing Suite
 
Large Language Models and the End of Programming
Large Language Models and the End of ProgrammingLarge Language Models and the End of Programming
Large Language Models and the End of Programming
 
Introduction to Pygame (Lecture 7 Python Game Development)
Introduction to Pygame (Lecture 7 Python Game Development)Introduction to Pygame (Lecture 7 Python Game Development)
Introduction to Pygame (Lecture 7 Python Game Development)
 
Text-Summarization-of-Breaking-News-Using-Fine-tuning-BART-Model.pptx
Text-Summarization-of-Breaking-News-Using-Fine-tuning-BART-Model.pptxText-Summarization-of-Breaking-News-Using-Fine-tuning-BART-Model.pptx
Text-Summarization-of-Breaking-News-Using-Fine-tuning-BART-Model.pptx
 
How Recreation Management Software Can Streamline Your Operations.pptx
How Recreation Management Software Can Streamline Your Operations.pptxHow Recreation Management Software Can Streamline Your Operations.pptx
How Recreation Management Software Can Streamline Your Operations.pptx
 
Cyaniclab : Software Development Agency Portfolio.pdf
Cyaniclab : Software Development Agency Portfolio.pdfCyaniclab : Software Development Agency Portfolio.pdf
Cyaniclab : Software Development Agency Portfolio.pdf
 
Developing Distributed High-performance Computing Capabilities of an Open Sci...
Developing Distributed High-performance Computing Capabilities of an Open Sci...Developing Distributed High-performance Computing Capabilities of an Open Sci...
Developing Distributed High-performance Computing Capabilities of an Open Sci...
 
Top Features to Include in Your Winzo Clone App for Business Growth (4).pptx
Top Features to Include in Your Winzo Clone App for Business Growth (4).pptxTop Features to Include in Your Winzo Clone App for Business Growth (4).pptx
Top Features to Include in Your Winzo Clone App for Business Growth (4).pptx
 
Quarkus Hidden and Forbidden Extensions
Quarkus Hidden and Forbidden ExtensionsQuarkus Hidden and Forbidden Extensions
Quarkus Hidden and Forbidden Extensions
 
A Sighting of filterA in Typelevel Rite of Passage
A Sighting of filterA in Typelevel Rite of PassageA Sighting of filterA in Typelevel Rite of Passage
A Sighting of filterA in Typelevel Rite of Passage
 
Understanding Globus Data Transfers with NetSage
Understanding Globus Data Transfers with NetSageUnderstanding Globus Data Transfers with NetSage
Understanding Globus Data Transfers with NetSage
 
Utilocate provides Smarter, Better, Faster, Safer Locate Ticket Management
Utilocate provides Smarter, Better, Faster, Safer Locate Ticket ManagementUtilocate provides Smarter, Better, Faster, Safer Locate Ticket Management
Utilocate provides Smarter, Better, Faster, Safer Locate Ticket Management
 
Lecture 1 Introduction to games development
Lecture 1 Introduction to games developmentLecture 1 Introduction to games development
Lecture 1 Introduction to games development
 
Vitthal Shirke Java Microservices Resume.pdf
Vitthal Shirke Java Microservices Resume.pdfVitthal Shirke Java Microservices Resume.pdf
Vitthal Shirke Java Microservices Resume.pdf
 
Top 7 Unique WhatsApp API Benefits | Saudi Arabia
Top 7 Unique WhatsApp API Benefits | Saudi ArabiaTop 7 Unique WhatsApp API Benefits | Saudi Arabia
Top 7 Unique WhatsApp API Benefits | Saudi Arabia
 
Climate Science Flows: Enabling Petabyte-Scale Climate Analysis with the Eart...
Climate Science Flows: Enabling Petabyte-Scale Climate Analysis with the Eart...Climate Science Flows: Enabling Petabyte-Scale Climate Analysis with the Eart...
Climate Science Flows: Enabling Petabyte-Scale Climate Analysis with the Eart...
 
Field Employee Tracking System| MiTrack App| Best Employee Tracking Solution|...
Field Employee Tracking System| MiTrack App| Best Employee Tracking Solution|...Field Employee Tracking System| MiTrack App| Best Employee Tracking Solution|...
Field Employee Tracking System| MiTrack App| Best Employee Tracking Solution|...
 
In 2015, I used to write extensions for Joomla, WordPress, phpBB3, etc and I ...
In 2015, I used to write extensions for Joomla, WordPress, phpBB3, etc and I ...In 2015, I used to write extensions for Joomla, WordPress, phpBB3, etc and I ...
In 2015, I used to write extensions for Joomla, WordPress, phpBB3, etc and I ...
 
May Marketo Masterclass, London MUG May 22 2024.pdf
May Marketo Masterclass, London MUG May 22 2024.pdfMay Marketo Masterclass, London MUG May 22 2024.pdf
May Marketo Masterclass, London MUG May 22 2024.pdf
 

API Versioning for Zero Downtime | Devoxx Belgium 2017

  • 1. API Versioning for Zero Downtime Patrice Krakow | ING | Lead Architect | APIs Devoxx Belgium 2017 Antwerp | 2017, November 8 (3.10.0)
  • 5. PSD2 Payment Services Directive 2015/2366 source: https://ec.europa.eu/info/law/payment-services-psd-2-directive-eu- 2015-2366_en 5 Why API?
  • 7. We want to be a tech company with a banking 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
  • 10. Patrice Krakow 10 Nordic API 2017 | A Journey from API Versioning to Canary Release https://youtu.be/Yke6Vut2Shc
  • 11. Patrice Krakow 11 • Sep 2016 – Present • ING | 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
  • 12. Patrice Krakow 12 • Sep 2016 – Present • ING | 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
  • 13. Why API Versioning? 13 “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 How?
  • 14. Why API Versioning? 14 “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 How? @mamund
  • 15. Why API Versioning? 15 2nd How?1st Why? “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
  • 16. Why API Versioning? 16 2nd How?1st Why? Versioning = 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
  • 18. Why API Versioning? 18 API Consumers API Providers
  • 19. Why API Versioning? 19 want to change their APIs as soon as they have a new brilliant idea API Consumers API Providers
  • 20. Why API Versioning? 20 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! API Consumers API Providers
  • 21. Why API Versioning? 21 What!? API Consumers 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!
  • 22. Why API Versioning? 22 API Versionin g API Consumers 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!
  • 23. Why API Versioning? 23 DON’ T API Consumers 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!
  • 27. • API is a set of API endpoints. • 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. 27 Meta-Model and Terminology for APIs Service API
  • 28. • API is a set of API endpoints. • 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
  • 29. • API is a set of API endpoints. • 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
  • 30. • API is a set of API endpoints that share 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
  • 31. • API is a set of API endpoints that share 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
  • 32. • API is a set of API endpoints that share 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
  • 33. • API is a set of API endpoints that share 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
  • 34. • API is a set of API endpoints that share 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
  • 35. • API is a set of API endpoints that share 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
  • 36. • API is a set of API endpoints that share 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
  • 37. • API is a set of API endpoints that share 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
  • 38. Semantic Versioning is a de-facto standard way – proposed by 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
  • 39. Semantic Versioning is a de-facto standard way – proposed by 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.PATCH or 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
  • 40. Semantic Versioning is a de-facto standard way – proposed by 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.PATCH or 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
  • 41. Semantic Versioning is a de-facto standard way – proposed by 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.PATCH or 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
  • 42. 10. Patch version Z(a) (x(a).y(a).Z(a) | x(a) > 0) of 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
  • 43. 10. Patch version Z(a) (x(a).y(a).Z(a) | x(a) > 0) of 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
  • 44. • API is a set of API endpoints that share 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
  • 45. Our Journey to Zero Downtime 45
  • 46. Our Journey to Zero Downtime 46 Meta-Model and Terminology for APIs
  • 47. Our Journey to Zero Downtime 47 Meta-Model and Terminology for APIs API Gateway
  • 48. Our Journey to Zero Downtime 48 Meta-Model and Terminology for APIs API Gateway API Service Discovery
  • 49. Our Journey to Zero Downtime 49 Meta-Model and Terminology for APIs API Gateway API Service Discovery API Registry
  • 50. Our Journey to Zero Downtime 50 Meta-Model and Terminology for APIs API Gateway API Service Discovery API Registry
  • 51. Our Journey to Zero Downtime 51 Meta-Model and Terminology for APIs API Gateway API Service Discovery Routing API Registry
  • 52. Our Journey to Zero Downtime 52 Meta-Model and Terminology for APIs API Gateway API Service Discovery Routing Canary Release API Registry
  • 53. Our Journey to Zero Downtime 53 Meta-Model and Terminology for APIs Zero Downtime API Gateway API Service Discovery Routing Canary Release API Registry
  • 54. Our Journey to Zero Downtime 54 Meta-Model and Terminology for APIs API Gateway API Service Discovery Routing Canary Release Zero Downtime API Registry
  • 55. API Platform 55 API Gateway API Service Discovery API Registry
  • 61. API Gateway 61 Outside Inside Office API Gateway on the external edge
  • 62. API Gateway 62 Outside Inside Office API Gateway on the external edge API Gateway on the internal edge
  • 64. API Service Discovery and Client-Side Load Balancing 64
  • 65. API Service Discovery and Client-Side Load Balancing 65 API Service Discovery
  • 66. API Service Discovery and Client-Side Load Balancing 66 API Service Discovery
  • 67. API Service Discovery and Client-Side Load Balancing 67 API Service Discovery { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" }
  • 68. API Service Discovery and Client-Side Load Balancing 68 Service~1 API Service Discovery { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" }
  • 69. API Service Discovery and Client-Side Load Balancing 69 Instance of Service~1 10.0.0.1:9001 API Service Discovery { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" }
  • 70. API Service Discovery and Client-Side Load Balancing 70 Instance of Service~1 10.0.0.1:9001 API Service Discovery { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" }
  • 71. API Service Discovery and Client-Side Load Balancing 71
  • 72. API Service Discovery and Client-Side Load Balancing 72 Instance of Service~1 10.0.0.1:9001 API Service Discovery { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" }
  • 73. API Service Discovery and Client-Side Load Balancing 73 Instance of Service~1 10.0.0.1:9001 API Service Discovery { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" }
  • 74. Logical Address Physical Address { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } API Service Discovery and Client-Side Load Balancing 74 Instance of Service~1 10.0.0.1:9001 API Service Discovery { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" }
  • 75. Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/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" }
  • 76. Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } API Service Discovery and Client-Side Load Balancing 76 { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } Instance of Service~1 10.0.0.1:9001 API Service Discovery
  • 77. Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/accounts" } API Service Discovery and Client-Side Load Balancing 77 { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } Instance of Service~1 10.0.0.1:9001 API Service Discovery
  • 78. Logical Address Physical Address { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/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
  • 79. Logical Address Physical Address { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/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
  • 80. Router Logical Address Physical Address { "method": “get", "host": “api.ing.com", "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
  • 81. Router Logical Address Physical Address { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } API Service Discovery and Client-Side Load Balancing 81 Instance of Service~1 10.0.0.1:9001 Instance of Application~1 { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } API Service Discovery
  • 82. Router Logical Address Physical Address { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } API Service Discovery and Client-Side Load Balancing 82 Instance of Service~1 10.0.0.1:9001 Instance of Application~1 { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } API Service Discovery
  • 83. Router Logical Address Physical Address { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } API Service Discovery and Client-Side Load Balancing 83 Instance of Service~1 10.0.0.1:9001 Instance of Application~1 { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } API Service Discovery
  • 84. Router Logical Address Physical Address { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } API Service Discovery and Client-Side Load Balancing 84 Instance of Service~1 10.0.0.1:9001 Instance of Application~1 { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } API Service Discovery
  • 85. Router Logical Address Physical Address { "method": “get", "host": “api.ing.com", "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
  • 86. Router Logical Address Physical Address { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } API Service Discovery and Client-Side Load Balancing 86 Instance of Service~1 10.0.0.1:9001 Instance of Application~1 Instance of Service~1 10.0.0.2:9001 API Service Discovery { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" }
  • 87. Logical Address Physical Address { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.2:9001", "urlPathTemplate": “/accounts" } API Service Discovery and Client-Side Load Balancing 87 Router Instance of Service~1 Instance of Service~1 10.0.0.1:9001 10.0.0.2:9001 Instance of Application~1 API Service Discovery { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" }
  • 88. Logical Address Physical Address { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.2:9001", "urlPathTemplate": “/accounts" } API Service Discovery and Client-Side Load Balancing 88 Router Instance of Service~1 Instance of Service~1 10.0.0.1:9001 10.0.0.2:9001 Instance of Application~1 API Service Discovery
  • 89. Logical Address Physical Address { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.2:9001", "urlPathTemplate": “/accounts" } API Service Discovery and Client-Side Load Balancing 89 Router Instance of Service~1 10.0.0.2:9001 Instance of Application~1 { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } API Service Discovery Instance of Service~1 10.0.0.1:9001
  • 90. Logical Address Physical Address { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.2:9001", "urlPathTemplate": “/accounts" } API Service Discovery and Client-Side Load Balancing 90 Router Instance of Service~1 10.0.0.2:9001 Instance of Application~1 { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } API Service Discovery Instance of Service~1 10.0.0.1:9001
  • 91. Logical Address Physical Address { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.2:9001", "urlPathTemplate": “/accounts" } API Service Discovery and Client-Side Load Balancing 91 Router Instance of Service~1 10.0.0.2:9001 Instance of Application~1 { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } API Service Discovery Instance of Service~1 10.0.0.1:9001
  • 92. Logical Address Physical Address { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.2:9001", "urlPathTemplate": “/accounts" } API Service Discovery and Client-Side Load Balancing 92 Router Instance of Service~1 10.0.0.2:9001 Instance of Application~1 { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } API Service Discovery Instance of Service~1 10.0.0.1:9001
  • 93. Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/accounts" } { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.2:9001", "urlPathTemplate": "/accounts" } API Service Discovery and Client-Side Load Balancing 93 Router Instance of Service~1 10.0.0.2:9001 Instance of Application~1 { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } API Service Discovery Instance of Service~1 10.0.0.1:9001
  • 94. Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/accounts" } { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.2:9001", "urlPathTemplate": "/accounts" } API Service Discovery and Client-Side Load Balancing 94
  • 95. API Service Discovery and Client-Side Load Balancing 95 Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/accounts" } { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.2:9001", "urlPathTemplate": "/accounts" }
  • 96. API Service Discovery and Client-Side Load Balancing 96 Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/accounts" } { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.2:9001", "urlPathTemplate": "/accounts" }
  • 97. API Service Discovery and Client-Side Load Balancing 97 Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/accounts" } { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.2:9001", "urlPathTemplate": "/accounts" }
  • 98. API Service Discovery and Client-Side Load Balancing 98 Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/accounts" } { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.2:9001", "urlPathTemplate": "/accounts" }
  • 99. API Service Discovery and Client-Side Load Balancing 99 Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/accounts" } { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.2:9001", "urlPathTemplate": "/accounts" }
  • 100. API Service Discovery and Client-Side Load Balancing 100 Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/accounts" } { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.2:9001", "urlPathTemplate": "/accounts" }
  • 101. API Service Discovery and Client-Side Load Balancing 101 Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/accounts" } { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } { "method": "get", "host": "10.0.0.2:9001", "urlPathTemplate": "/accounts" }
  • 102. API Service Discovery and Client-Side Load Balancing 102 Why not DNS?
  • 103. API Service Discovery and Client-Side Load Balancing 103
  • 104. API Service Discovery and Client-Side Load Balancing 104
  • 105. • API is a set of API endpoints that share 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
  • 106. • API is a set of API endpoints that share 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
  • 107. { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 107
  • 108. { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 108
  • 109. API Service Discovery and Client-Side Load Balancing 109 Service~2 Service~1 { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" }
  • 110. API Service Discovery and Client-Side Load Balancing 110 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" }
  • 111. API Service Discovery and Client-Side Load Balancing 111 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } Logical Address Physical Address { "method": “get", "host": “api.ing.com", "urlPathTemplate": “/accounts" } { "method": “get", "host": “10.0.0.1:9001", "urlPathTemplate": “/accounts" } API Service Discovery
  • 112. Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 112 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } API Service Discovery
  • 113. Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payments" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 113 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } API Service Discovery
  • 114. Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payments" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 114 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 API Service Discovery
  • 115. Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payments" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 115 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 API Service Discovery Router Instance of Application~1
  • 116. Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payments" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 116 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 API Service Discovery Router Instance of Application~1 { "method": "get", "host": “api.ing.com", "urlPathTemplate": “/payments" }
  • 117. Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payments" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 117 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 API Service Discovery Router Instance of Application~1 { "method": "get", "host": “api.ing.com", "urlPathTemplate": “/payments" }
  • 118. Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payments" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 118 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 API Service Discovery Router Instance of Application~1 { "method": "get", "host": “api.ing.com", "urlPathTemplate": “/payments" }
  • 119. Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payments" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 119 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 API Service Discovery Router Instance of Application~1 { "method": "get", "host": “api.ing.com", "urlPathTemplate": “/payments" }
  • 120. Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payments" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 120 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 API Service Discovery Router Instance of Application~1 { "method": "get", "host": “api.ing.com", "urlPathTemplate": “/payments" }
  • 121. Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payments" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 121 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 API Service Discovery Router Instance of Application~1 { "method": "post", "host": “api.ing.com", "urlPathTemplate": “/payments" }
  • 122. Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payments" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 122 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 API Service Discovery Router Instance of Application~1 { "method": "post", "host": “api.ing.com", "urlPathTemplate": “/payments" }
  • 123. Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payments" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 123 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 API Service Discovery Router Instance of Application~1 { "method": "post", "host": “api.ing.com", "urlPathTemplate": “/payments" }
  • 124. Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payments" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 124 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 API Service Discovery Router Instance of Application~1 { "method": "post", "host": “api.ing.com", "urlPathTemplate": “/payments" }
  • 125. Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payments" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 125 Instance of Service~2 10.0.0.2:9001 Instance of Service~1 10.0.0.1:9001 API Service Discovery Router Instance of Application~1
  • 126. Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payments" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" } API Service Discovery and Client-Side Load Balancing 126
  • 127. API Service Discovery and Client-Side Load Balancing 127 Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payment" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" }
  • 128. API Service Discovery and Client-Side Load Balancing 128 Logical Address Physical Address { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "get", "host": "10.0.0.1:9001", "urlPathTemplate": "/payment" } { "method": "post", "host": "api.ing.com", "urlPathTemplate": "/payments" } { "method": "post", "host": "10.0.0.2:9001", "urlPathTemplate": "/payments" } DNS
  • 129. API Service Discovery and Client-Side Load Balancing 129
  • 130. API Service Discovery and Client-Side Load Balancing 130
  • 133. API Service Discovery and Client-Side Load Balancing 133
  • 134. API Service Discovery and Client-Side Load Balancing 134
  • 135. In particular, [Baker Street] creates a simpler management model: there 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
  • 138. API Registry 138 { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" }
  • 139. API Registry 139 { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" }
  • 140. API Registry 140 { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" }
  • 141. API Registry 141 { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } Swagger 2.0
  • 142. API Registry 142 { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } Swagger 2.0
  • 143. API Registry 143 { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } Swagger 2.0 OpenAPI/Swagger 2.0
  • 144. DON’T write “micro service”, but “microservice”! 144
  • 145. DON’T mix “Open API” and “OpenAPI”! 145
  • 146. API Registry 146 { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } Swagger 2.0 OpenAPI/Swagger 2.0
  • 147. API Registry 147 { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } Swagger 2.0 OpenAPI/Swagger 2.0  OpenAPI 3.0
  • 148. API Registry 148 { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } Swagger 2.0 OpenAPI/Swagger 2.0 https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md
  • 149. API Registry 149 { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } swagger: '2.0' info: title: Account Information API version: 1.0.1 host: api.ing.com basePath: / schemes: - https consumes: - application/json produces: - application/json paths: /accounts: get: parameters: - ...
  • 150. API Registry 150 { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } swagger: '2.0' info: title: Account Information API version: 1.0.1 host: api.ing.com basePath: / schemes: - https consumes: - application/json produces: - application/json paths: /accounts: get: parameters: - ... API Registry
  • 151. API Registry 151 Router Instance of Service~1 10.0.0.1:9001 Instance of Application~1 API Service Discovery API Registry
  • 152. API Registry 152 Router Instance of Application~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 API Registry
  • 153. API Registry 153 Router Instance of Application~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 API Registry
  • 154. API Registry 154 Router Instance of Application~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 API Provider API Registry
  • 155. API Registry 155 Router Instance of Application~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 API ProviderAPI Consumer API Registry
  • 156. API Registry 156 Router Instance of Application~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 API ProviderAPI Consumer API Registry
  • 157. API Registry 157 Router Instance of Application~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 Is this service allowed to implement this API endpoint? API ProviderAPI Consumer API Registry
  • 158. API Registry 158 Router Instance of Application~1 API Service Discovery 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 ProviderAPI Consumer API Registry
  • 159. API Registry 159 Router Instance of Application~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 Manifest Is this application allowed to call this API endpoint? API Registry API ProviderAPI Consumer
  • 160. API Registry 160 Router Instance of Application~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 Manifest Subscription API Registry API ProviderAPI Consumer
  • 161. API Registry 161 Router Instance of Application~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 Manifest (Subscription) Peer-Token API Registry API ProviderAPI Consumer
  • 162. Within our organization, we want to control which service is implementing which part of an API. The Manifest 162 API endpoint API specification Xa.Ya.Za Service Service version Xs.Ys.Zs Instance API
  • 163. Within our organization, we want to control which service is 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
  • 164. Within our organization, we want to control which service is 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 specification that 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
  • 165. { "serviceName": "<Name of the Service>", "endpoints": [ { "method": "<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
  • 166. { "serviceName": "<Name of the Service>", "endpoints": [ { "method": "<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 166 Service~1 { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" }
  • 167. { "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": “1.0.1" }, ... ] } The Manifest 167 Service~1 { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } swagger: '2.0' info: title: Account Information API version: 1.0.1 host: api.ing.com basePath: / schemes: - https consumes: - application/json produces: - application/json paths: /accounts: get: parameters: - ...
  • 169. When a software package wants to call an API endpoint, 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
  • 170. When a software package wants to call an API endpoint, 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 SubscriptionApplication
  • 172. When a software package wants to call an API endpoint, 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
  • 173. { “applicationName": "<Name of the Application>", "endpoints": [ { "method": "<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
  • 174. { “applicationName": "<Name of the Application>", "endpoints": [ { "method": "<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 ;-)
  • 176. { "applicationName": "Application~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.1" }, ... ] } Subscription and Peer-Token 176
  • 177. API Platform 177 API Gateway API Service Discovery API Registry
  • 179. API Platform 179 API endpoint API specification Xa.Ya.Za API 1 0..n 1 1
  • 180. API Platform 180 API endpoint API specification Xa.Ya.Za API 1 0..n 1 1 API Registry
  • 181. API Platform 181 API endpoint API specification Xa.Ya.Za API 1 0..n 1 1 API Registry API Developer Portal
  • 183. API Platform 183 API endpoint API specification Xa.Ya.Za API 1 0..n 1 1 API Registry API Developer Portal
  • 184. API Platform 184 API endpoint API specification Xa.Ya.Za API 1 0..n 1 1 API Registry API Developer Portal Service 1 1..n Service~1
  • 185. API Platform 185 API endpoint API specification Xa.Ya.Za API 1 0..n 1 1 API Registry API Developer Portal Service 1 1..n Service~1 Manifest Manifest
  • 186. API Platform 186 API endpoint API specification Xa.Ya.Za API 1 0..n 1 1 API Registry API Developer Portal Service 1 1..n Service~1 Manifest Manifest
  • 187. API Platform 187 API endpoint API specification Xa.Ya.Za API 1 0..n 1 1 API Registry API Developer Portal Service 1 1..n Service~1 Manifest Manifest Service version Xs.Ys.Zs 1 0..n
  • 188. API Platform 188 API endpoint API specification Xa.Ya.Za API 1 0..n 1 1 API Registry API Developer Portal Service 1 1..n Service~1 Manifest Manifest Service version Xs.Ys.Zs 1 0..n API Provider
  • 189. API Platform 189 API endpoint API specification Xa.Ya.Za API 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
  • 190. API Platform 190 API endpoint API specification Xa.Ya.Za API 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
  • 191. API Platform 191 API endpoint API specification Xa.Ya.Za API 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
  • 192. API Platform 192 API endpoint API specification Xa.Ya.Za API 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 Router Instance of Application~1 API Consumer
  • 193. API Platform 193 API endpoint API specification Xa.Ya.Za API 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 Router Instance of Application~1 API Consumer
  • 194. API Platform 194 API endpoint API specification Xa.Ya.Za API 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 Router Instance of Application~1 API Consumer Peer-Token (Subscription) Peer-Token Application
  • 195. API Platform 195 API endpoint API specification Xa.Ya.Za API 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 Router Instance of Application~1 API Consumer Peer-Token (Subscription) Peer-Token Application
  • 196. Router API Platform 196 API endpoint API specification Xa.Ya.Za API 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
  • 197. Router API Platform 197 API endpoint API specification Xa.Ya.Za API 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
  • 198. API Platform 198 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 Router Instance of Application~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 API ProviderAPI Consumer API Registry API Developer Portal API SDK SDK Peer-Token Manifest (Subscription) Peer-Token Application Manifest
  • 200. Routing Conjecture 200 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 Router Instance of Application~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 API ProviderAPI Consumer API Registry API Developer Portal API SDK SDK Peer-Token Manifest (Subscription) Peer-Token Application Manifest
  • 201. Routing Conjecture 201 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 Router Instance of Application~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 API ProviderAPI Consumer API Registry API Developer Portal API SDK SDK Peer-Token Manifest (Subscription) Peer-Token Application Manifest
  • 202. Routing Conjecture 202 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 Router Instance of Application~1 API Service Discovery Instance of Service~1 10.0.0.1:9001 API ProviderAPI Consumer API Registry API Developer Portal API SDK SDK Peer-Token Manifest (Subscription) Peer-Token Application Manifest
  • 203. The canary release is a technique to reduce the risk 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
  • 204. The canary release is a technique to reduce the risk 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
  • 206. Canary Release 206 Application~1 Router Instance of Service~1 v1.1.0 Instance of Service~1 v1.0.0
  • 207. Canary Release 207 Application~1 Router Instance of Service~1 v1.1.0 Instance of Service~1 v1.0.0 100% 10% 90%
  • 208. Canary Release 208 Application~1 Router Instance of Service~1 v1.1.0 Instance of Service~1 v1.0.0 100% 50% 50%
  • 209. Canary Release 209 Application~1 Router Instance of Service~1 v1.1.0 Instance of Service~1 v1.0.0 100% 90% 10%
  • 210. Canary Release 210 Application~1 Router Instance of Service~1 v1.1.0 Instance of Service~1 v1.0.0 100% 100%
  • 211. We can now implement the Canary Release, but let’s be 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
  • 212. We can now implement the Canary Release, but let’s be 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
  • 213. We can now implement the Canary Release, but let’s be 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
  • 214. We can now implement the Canary Release, but let’s be 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
  • 215. We can now implement the Canary Release, but let’s be 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
  • 216. We can now implement the Canary Release, but let’s be 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
  • 217. We can now implement the Canary Release, but let’s be 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
  • 221. Routing 221 swagger: '2.0' info: title: Account Information API version: 1.0.3 host: api.ing.com basePath: / schemes: - https paths: /accounts: get: parameters: - ... { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } v1.0.3
  • 222. Routing 222 API Registry swagger: '2.0' info: title: Account Information API version: 1.0.3 host: api.ing.com basePath: / schemes: - https paths: /accounts: get: parameters: - ... { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } v1.0.3
  • 223. Routing 223 API Registry API Developer Portal swagger: '2.0' info: title: Account Information API version: 1.0.3 host: api.ing.com basePath: / schemes: - https paths: /accounts: get: parameters: - ... { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts" } v1.0.3
  • 224. Routing 224 API Registry API Developer Portal v1.0.3 swagger: '2.0' info: title: Account Information API version: 1.0.3 host: api.ing.com basePath: / schemes: - https paths: /accounts: get: parameters: - ...
  • 225. Routing 225 API Registry API Developer Portal Service~1v1.0.3 swagger: '2.0' info: title: Account Information API version: 1.0.3 host: api.ing.com basePath: / schemes: - https paths: /accounts: get: parameters: - ...
  • 226. Routing 226 v1.0.3 API Registry API Developer Portal Service~1 Manifest { "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } swagger: '2.0' info: title: Account Information API version: 1.0.3 host: api.ing.com basePath: / schemes: - https paths: /accounts: get: parameters: - ...
  • 227. Routing 227 v1.0.3 API Registry API Developer Portal Service~1 Manifest { "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] }
  • 228. Routing 228 v1.0.3 API Registry API Developer Portal Service~1 Manifest { "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] }
  • 229. Routing 229 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest 10.0.0.1:9001 { "serviceName": “Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] }
  • 230. Routing 230 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest 10.0.0.1:9001 { "serviceName": “Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] }
  • 231. Routing 231 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest { "serviceName": “Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } 10.0.0.1:9001 API Service Discovery
  • 232. Routing 232 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest { "serviceName": “Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } 10.0.0.1:9001 API Service Discovery { "ip": "10.0.0.1:9001", "port": "9001" }
  • 233. Routing 233 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest { "serviceName": “Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } 10.0.0.1:9001 API Service Discovery { "ip": "10.0.0.1:9001", "port": "9001", "manifest": { "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } }
  • 234. Routing 234 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest 10.0.0.1:9001 API Service Discovery { "ip": "10.0.0.1:9001", "port": "9001", "manifest": { "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } }
  • 235. { "ip": "10.0.0.1:9001", "port": "9001", "manifest": { "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } } Routing 235 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest 10.0.0.1:9001 API Service Discovery
  • 236. { "ip": "10.0.0.1:9001", "port": "9001", "manifest": { "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } } Routing 236 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest 10.0.0.1:9001 API Service Discovery
  • 237. { "ip": "10.0.0.1:9001", "port": "9001", "manifest": { "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } } Routing 237 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest 10.0.0.1:9001 API Service Discovery Application~1
  • 238. { "ip": "10.0.0.1:9001", "port": "9001", "manifest": { "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } } Routing 238 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest 10.0.0.1:9001 API Service Discovery Application~1 (when v1.0.3) Subscription
  • 239. { "ip": "10.0.0.1:9001", "port": "9001", "manifest": { "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } } Routing 239 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest 10.0.0.1:9001 API Service Discovery Application~1 (when v1.0.3) Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] }
  • 240. { "ip": "10.0.0.1:9001", "port": "9001", "manifest": { "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } } Routing 240 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest 10.0.0.1:9001 API Service Discovery Instance of Application~1 (when v1.0.3) Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] }
  • 241. Router { "ip": "10.0.0.1:9001", "port": "9001", "manifest": { "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } } Routing 241 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest 10.0.0.1:9001 API Service Discovery Instance of Application~1 (when v1.0.3) Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } API SDK
  • 242. Router { "ip": "10.0.0.1:9001", "port": "9001", "manifest": { "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } } Routing 242 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest 10.0.0.1:9001 API Service Discovery Instance of Application~1 (when v1.0.3) Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } API SDK Peer-Token
  • 243. Router { "ip": "10.0.0.1:9001", "port": "9001", "manifest": { "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } } Routing 243 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest 10.0.0.1:9001 API Service Discovery Instance of Application~1 (when v1.0.3) Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } API SDK Peer-Token
  • 244. Router { "ip": "10.0.0.1:9001", "port": "9001", "manifest": { "serviceName": "Service~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } } Routing 244 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest 10.0.0.1:9001 API Service Discovery Instance of Application~1 (when v1.0.3) Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } API SDK Peer-Token [ { "ip": "10.0.0.1", "port": "9001", "apiSpecificationVersion": "1.0.3" } ]
  • 245. Router Routing 245 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest 10.0.0.1:9001 API Service Discovery Instance of Application~1 (when v1.0.3) Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } API SDK Peer-Token [ { "ip": "10.0.0.1", "port": "9001", "apiSpecificationVersion": "1.0.3" } ]
  • 246. Router Routing 246 v1.0.3 API Registry API Developer Portal Instance of Service~1 v1.0.5 Manifest 10.0.0.1:9001 API Service Discovery Instance of Application~1 (when v1.0.3) Subscription { “applicationName": "Application~1", "endpoints": [ { "method": "get", "host": "api.ing.com", "urlPathTemplate": "/accounts", "apiSpecificationVersion": "1.0.3" } ] } API SDK Peer-Token [ { "ip": "10.0.0.1", "port": "9001", "apiSpecificationVersion": "1.0.3" } ]

Editor's Notes

  1. And, to paraphrase Roy Fielding…