Creating APIs that sustain the test of time

#todayilearned #api #architecture #microservices

TL;DR notes from articles I read today.

To build an evolvable API, instead of forcing clients to have prior knowledge of URLs, fields and HTTP methods, you should let the client ask the server what is required to complete an operation and indicate the preferred host and path.
Critical aspects of evolvable API include: a) The state of the conversation being stored in the network - not sourced from either client or server. b) No versioning needed - when you add or remove data from a response, clients should know how to react. If they don’t know how to react to a new feature, they should be able to ignore it and work in the old way. c) The server owns actions which contain values for URLs, methods, and fields, so that they control where clients go to continue the conversation, with only the entry point hardcoded in the client.  
With control of URLs in the server, it can run A/B testing and direct clients to different servers running the same instance of the application. The server can also implement a polling functionality to track the status of requests.
Model communication on how people actually operate. Think not only about a generic language but developing a shared domain vocabulary.

Full post here, 10 mins read

An API gateway is a central interface for all external communications. It typically works by invoking multiple microservices and aggregating results to determine the best path.
It may also handle authentication, input validation and filtering, and metric collection, as well as transforming requests and/or results. For the microservices network, it offers lower latency, better efficiency and higher security, as well as easier isolation of single sources of failure.
API microgateways are proxies sitting close to microservices for internal communication between microservices, allowing better governance, discovery, observability, and stability for developers and expose the policy enforcement point and security controls to operators.
They are a more granular solution than a single API gateway due to the control of exposure. They offer low latency and a small footprint, as requests don’t need to wait their turn. This does imply code duplication across multiple microservice instances, which can be inefficient if code is not intelligently structured.
A service mesh is a layer between microservices for all service-to-service communication that replaces direct communication between services. It will often have in-built support for resiliency, error checking, and service discovery. It is similar to a microgateway but with network communications entirely abstracted from business logic, allowing developers to focus entirely on the latter.

Full post here, 8 mins read