Let's talk about the design of micro services based on rest and HTTP to achieve loosely coupled independent services. One of the most important aspects of microservices based applications, is the ability to deploy microservices completely independent of one another. To achieve this independence, each micro service must provide a version well defined contract to its clients, which are other microservices or applications. Each service must not break these version contracts, until it's known that no other microservice relies on a particular version contract. Remember that other microservices may need to roll back to a previous code version that requires a previous contract. So, it's important to account for this fact in your deprecation and turn down policies. A culture around strong version contracts, is probably the most challenging organizational aspect of a stable microservices based application. At the lower level of detail, services communicate using HTTPS with text based payloads, for example, JSON or XML and use the HTTP warps such as GET and POST to provide meaning for the actions requested. Clients should just need to know the minimal details to use the service, the URL ,the request and the response message formats. REST architecture supports loose coupling, REST stands for representational state transfer and is protocol independent. The HTTP is the most common protocol but gRPC is also widely used. REST supports loose coupling, but still requires strong engineering practices to maintain that loose coupling. A starting point is to have a strong contract. HTTP based implementations can use a standard like open API and gRPC provides protocol buffers. To help maintain loose coupling, it is vital to maintain backward compatibility of the contract and to design an API around the domain and not particular use cases or clients. If the latter is the case, each new use case or application will require another special purpose rest API regardless of the protocol. While request response processing is the typical use case, streaming may also be required and can influence the choice of protocol, gRPC supports streaming for example. Resources are identified by URIs or endpoints and responses to requests return an immutable representation of the resource information. REST applications, should provide consistent uniform interfaces and can link to additional resources. Hyper media as the engine of application state, is a component of REST that allows the client to require little prior knowledge of a service because links to additional resources are provided as part of the responses. It is important that API design is part of the development process, ideally a set of API design rules is in place that helps the rest APIs provide a uniform interface, for example, each service reports error consistently. The structure of the URL is consistent and the use of paging is consistent. Also consider Caching for performance and resource optimization for immutable resources. In REST, a client and server exchange representations of a resource, a resource is an abstract notion of information. The representation of a resource, is a copy of the resource information. For example, a resource could represent a dog, the representation of a resource is the actual data for a particular dog. For example, Noir who is a schnoodle or Bree who is a mutt, two different representations of a resource. The URI provides access to a resource, making a request for that resource returns a representation of that resource. Usually in JSON format, the resources requested can be single items or a collection of items for performance reasons, returning collection of items instead of individual items can be beneficial. These types of operations are often referred to as batch APIs. Representation of a resource between client and services are usually achieved using text based standard formats. JSON is the norm for text based formats, although XML can be used as well. For public facing or external facing APIs, JSON is the standard, for internal services gRPC may be used in particular if performance is key.
