Home

Awesome

Microservices Recipes- a free gitbook

Microservices are small, autonomous services that work together.

Alt Text

Table of Contents


Definition

Microservice architecture, or simply microservices, is a distinctive method of developing software systems that tries to focus on building single-function modules with well-defined interfaces and operations. The trend has grown popular in recent years as Enterprises look to become more Agile and move towards a DevOps and continuous testing. Microservices can help create scalable, testable software that can be delivered weekly, not yearly.

Alt Text

Microservices architecture (courtesy: Cloud Application Architecture Guide and smartbear).

Microservices Definition by Lewis/Fowler:

“Microservices are important simply because they add unique value in a way of simplification of complexity in systems. By breaking apart your system or application into many smaller parts, you show ways of reducing duplication, increasing cohesion and lowering your coupling between parts, thus making your overall system parts easier to understand, more scalable, and easier to change. The downside of a distributed system is that it is always more complex from a systems standpoint. The overhead of many small services to manage is another factor to consider. ” ― Lucas Krause,

The Microservices approach is about breaking your system ("pile of code") into many small services, each typically has its own:

Why-Microservice

When-to-use-microservice-architecture

Consider this architecture style for:

Pros-and-cons

Advantages

Sam Newman in Building Microservices, enumerates the key benefits of Microservices as following:

Technology Heterogeneity

With a system composed of multiple, collaborating services, we can decide to use different technologies inside each one. This allows us to pick the right tool for each job, rather than having to select a more standardized, one-size-fits-all approach that often ends up being the lowest common denominator.

Resilience

A key concept in resilience engineering is the bulkhead. If one component of a system fails, but that failure doesn’t cascade, you can isolate the problem and the rest of the system can carry on working. Service boundaries become your obvious bulkheads. In a monolithic service, if the service fails, everything stops working. With a monolithic system, we can run on multiple machines to reduce our chance of failure, but with microservices, we can build systems that handle the total failure of services and degrade functionality accordingly.

Scaling

With a large, monolithic service, we have to scale everything together. One small part of our overall system is constrained in performance, but if that behavior is locked up in a giant monolithic application, we have to handle scaling everything as a piece. With smaller services, we can just scale those services that need scaling, allowing us to run other parts of the system on smaller, less powerful hardware.

Ease of Deployment

A one-line change to a million-line-long monolithic application requires the whole application to be deployed in order to release the change. That could be a large-impact, high-risk deployment. In practice, large-impact, high-risk deployments end up happening infrequently due to understandable fear.

With microservices, we can make a change to a single service and deploy it independently of the rest of the system. This allows us to get our code deployed faster. If a problem does occur, it can be isolated quickly to an individual service, making fast rollback easy to achieve.

Organizational Alignment

Microservices allow us to better align our architecture to our organization, helping us minimize the number of people working on any one codebase to hit the sweet spot of team size and productivity. We can also shift ownership of services between teams to try to keep people working on one service collocated.

Composability

One of the key promises of distributed systems and service-oriented architectures is that we open up opportunities for reuse of functionality. With microservices, we allow for our functionality to be consumed in different ways for different purposes. This can be especially important when we think about how our consumers use our software.

Optimizing for Replaceability

If you work at a medium-size or bigger organization, chances are you are aware of some big, nasty legacy system sitting in the corner. The one no one wants to touch. The one that is vital to how your company runs, but that happens to be written in some odd Fortran variant and runs only on hardware that reached end of life 25 years ago. Why hasn’t it been replaced? You know why: it’s too big and risky a job.

With our individual services being small in size, the cost to replace them with a better implementation, or even delete them altogether, is much easier to manage.

Disadvantages

Team Communication Overhead -

Microservice architecture reduces the team management complexity, but it is not able to diminish the need of team communication. They need to make sure an update in one’s service is not breaking some other functionality. We can find this problem in monolith architecture applications too.

Non uniform application -

We can choose a different technology stack for a different component (polyglot). It leads to the problem of non uniform application design and architecture. It may can increase maintenance cost in the long run.

Dev Ops complexity -

We need to have a mature Dev Ops team to handle the complexity involved in maintaining Microservice based application. Due to several moving parts of the application, it becomes complex and requires a high level of expertise. Increased Resource use - Initial investment to run these applications are high because all the independently running components need their own runtime containers with more memory and CPU.

Increase Network communication -

Independently running components interact with each other over a network. Such systems require reliable and fast network connections. Marshalling and Un marshalling - When one component needs data from another component, the sender marshals the data in some standard from its internal representation, while the receiver un-marshalls data into its own representation before use. This definitely requires more processing compared to conventional application architecture.

Network Security -

Inter Service Communication needs to be secured to avoid any inter communication security breach. Due to several moving parts, these applications are more prone to security vulnerabilities.

Testing -

Testing of such application is definitely harder compared to a monolith application.

Production monitoring -

Unavailability of the right tools are also an issue to be considered.

Log analysis -

Need log analysis tool for log analysis ,Splunk or ELK stack

Alt Text (Image courtesy:pivotal)

Design Guidelines

Architecture Principles

Core patterns

Deployment patterns

Service discovery

Service Mesh

Strategies and patterns for realizing the seven design guidelines applied to microservices (sei.cmu.edu)

Standardized service contract. Strategies include:

Service loose coupling. Strategies include:

Service reusability. Strategies include:

Service autonomy. Strategies include:

Service statelessness. Strategies include:

Service discoverability. Strategies include:

Service deployability. Strategies include:

asciicast

Microservice Design Patterns

Guidelines and examples for White House Web APIs, encouraging consistency, maintainability, and best practices across applications. White House APIs aim to balance a truly RESTful API interface with a positive developer experience (DX).

This document borrows heavily from:

Certify-microservices-design :

After you identify the microservices in your application, validate your design against the following criteria:

Can we reuse Microservice ?

Reuse continues to be a principle of microservice design. However, the scope of reuse has been reduced to specific domains within the business. The effort of designing for this reuse, which in the early days of SOA included wasted efforts in designing enterprise-wide canonical models, was fruitless because it was too ambitious.

However, it must be noted that the canonical model in its restricted scope can be of benefit. In line with the reuse it facilitates, its scope has been reduced. With the ‘merit based reuse’ approach, an emerging model is preferred over a predetermined one. Teams can agree on communication models for deciding how microservices must be adapted for use outside the contexts in which they were designed.

If an existing microservice API does not suit your domain or ‘business group’, you might be better off building another microservice that does it.

-Alison Jarris

Know where you stand or going in future Architecture

Alt Text

The-Scale-Cube

Scale Cube, defined by Martin L. Abbott and Michael T. Fisher. This model explains how infinite scaling can be achieved by implementing a three-dimensional approach.

The Art of Scalability book describes three dimension scalability model: the scale cube. The microservice architecture is an application of Y-axis scaling on the scale cube.

•	Horizontal Duplication and Cloning (X-Axis )
•	Functional Decomposition and Segmentation - Microservices (Y-Axis)
•	Horizontal Data Partitioning - Shards (Z-Axis)

Alt Text

Scale Cube (Image courtesy:microservices.io)

Microservices-vs-SOA

Alt Text

Microservices-vs-API

APIs are standardized wrappers that create an interface through which microservices can be packaged and surfaced. This makes APIs the logical enforcement point for key concerns of a microservices architecture such as security, governance, and reuse. Because APIs are able to house these concerns, they are considered a foundational component of a microservices architecture(mulesoft).
Microservices are design to use internally, while APIs are used to expose functionality to the outside world.

Microservice-vs-Miniservice

Miniservices have been called pragmatic microservices. You can get started with them faster and pick and choose the pieces that make sense for your team.

“[A miniservice is] like a group of microservices come together in a little pattern.” — Ross Garrett

“Each microservice must handle its own data, miniservices may share data.” — Arnaud Lauret

Don’t confuse architectural perfection with business value.” — Ross Garrett

Leveraging the pieces of that practice that makes sense for me and getting most of the functionality benefits," says Ross Garrett.

Microservice-vs-Nanoservices

Nanoservice is an antipattern where a service is too fine-grained. A nanoservice is a service whose overhead (communications, maintenance, and so on) outweighs its utility.

What-is-BoundedContext

DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships. Martin fowler

How big a Microservice should be is: it should have a well defined bounded context that will enable us to work without having to consider, or swap, between contexts.

How to identify bounded context ?

Real-Life-Sucess-Stories

Alt Text


Orchestrate vs Choreography

Service orchestration

The relationship between all the participating services are described by a single endpoint

Service Choreography

Service choreography is a global description of the participating services, which is defined by exchange of messages, rules of interaction and agreements between two or more endpoints. Choreography employs a decentralized approach for service composition.

andrei from stack

"We came across the decision to orchestrate our microservices by using a "god" like service that controls the business logic or a choreographed approach where the microservices basically pass messages, In microservice architecture choreography is preferred over orchestration."

Orchestrate-microservices

If you create own orchestration Remember:


Theory

Alt Text

Articles & Papers


Talks

Tutorials

Books

Sites

Microservices-Quotes

Resource-Naming


Microservices-Video

Alt Text

Noabouturl
1What are the Advantages of Microservices? - Sam Newman- https://www.youtube.com/watch?v=KV3j3MZTXgk
2Design Microservice Architectures the Right Way- https://www.youtube.com/watch?v=j6ow-UemzBc
3Mastering Chaos - A Netflix Guide to Microservices- https://www.youtube.com/watch?v=CZ3wIuvmHeM
4API Academy Microservices Boot Camp @ CA World: Designing a Microservices Architecture-https://www.youtube.com/watch?v=iZNSPKxAd5w
5Data Strategies for Microservice Architectures- https://www.youtube.com/watch?v=n_V8hBRoshY
6Refactor your Java EE application using Microservices and Containers by Arun Gupta-https://www.youtube.com/watch?v=iJVW7v8O9BU
7Principles Of Microservices by Sam Newman s-https://www.youtube.com/watch?v=PFQnNFe27kU
8PGOTO 2016 • Appsec and Microservices • Sam Newman- https://www.youtube.com/watch?v=wlt7nCRWx_w
9Avoiding Microservice Megadisasters - Jimmy Bogard- https://www.youtube.com/watch?v=gfh-VCTwMw8
1010 Tips for failing badly at Microservices by David Schmitz- https://www.youtube.com/watch?v=X0tjziAQfNQ
11Lessons from the Birth of Microservices at Google- https://www.youtube.com/watch?v=Fz1PoXqxAZc
12Event Sourcing You are doing it wrong by David Schmitz- https://www.youtube.com/watch?v=GzrZworHpIk
13The hardest part of microservices is your data- https://www.youtube.com/watch?v=MrV0DqTqpFU
14Data Design and Modeling for Microservices- https://www.youtube.com/watch?v=KPtLbSEFe6c
15The Art of Discovering Bounded Contexts by Nick Tune- https://www.youtube.com/watch?v=ez9GWESKG4I
16The challenges of migrating 150+ microservices to Kubernetes -Sarah Wells (Financial Times)- https://www.youtube.com/watch?v=fgI3cOdv87I&feature=youtu.be
17Revitalizing Aging Architectures with Microservices- https://www.youtube.com/watch?v=SPGCdziXlHU

Microservices-Patterns

Noabouturl
1Developing Microservices with Aggregates Chris Richardson- https://www.infoq.com/presentations/aggregates-modular-microservices
2Top 5+ Microservices Architecture and Design Best Practices Ajitesh Kumar- https://dzone.com/articles/top-5-microservices-architecture-and-design-best-p
3Microservices: Patterns and Practices Panel C. Richardson, R. Shoup, L. Ryan, R. Tangirala, and R. Schloming participate in a discussion on microservices and the challenges faced at scale, the strategies to use and more.-https://www.infoq.com/presentations/microservices-patterns-practices-panel
4Microservices Patterns Red Hat Videos- https://www.youtube.com/watch?v=_YzzxrSIQGw
57 Microservice Patterns Explained (Ivar Grimstad)- https://www.youtube.com/watch?v=4IFVBfLBl1Y
6Three Microservice Patterns to Tear Down Your Monoliths- https://www.youtube.com/watch?v=84W9iY3CwdQ
714 Architectural patterns for microservice development- https://www.youtube.com/watch?v=yVZS1HZrlEw
8Reducing Microservices Architecture Complexity with Istio and Kubernetes- https://www.youtube.com/watch?v=k42jqkjtYKY
9Developing Microservices with Aggregates- https://www.infoq.com/presentations/aggregates-modular-microservices
10The Seven Deadly Sins of Microservices by Daniel Bryant- https://www.youtube.com/watch?v=Jw6TYEb1Opw
11Microservices Anti-Patterns- https://www.youtube.com/watch?v=I56HzTKvZKc

Code-example

Alt Text

Nourl
1- https://github.com/vaquarkhan/microservice-poc
2- https://github.com/vaquarkhan/robot-shop
3- https://github.com/vaquarkhan/awesome-microservices
4- https://github.com/vaquarkhan/microservice-docker-project
5- https://github.com/vaquarkhan/flowing-retail-microservice-kafka
6- https://github.com/vaquarkhan/spring-boot-microservices-series
7- https://github.com/vaquarkhan/A-curated-list-of-Microservice
8- https://github.com/vaquarkhan/sample-spring-microservices
9- https://github.com/vaquarkhan/microservice-kafka
10- https://github.com/vaquarkhan/oreilly-building-microservices-training
11- https://github.com/vaquarkhan/micromono
12- https://github.com/vaquarkhan/spring-cloud-microservice-example
13- https://github.com/vaquarkhan/jwt-microservices-JavaRoadStorm2016
14- https://github.com/vaquarkhan/micro
15- https://github.com/vaquarkhan/microservices-centralized-configuration
16- https://github.com/vaquarkhan/micro-company
17- https://github.com/vaquarkhan/PiggyMetrics-microservice-poc
18- https://github.com/vaquarkhan/spring-cloud-microservice
19- https://github.com/vaquarkhan/CQRS-microservice-sampler
20- https://github.com/vaquarkhan/Microservices-Deployment-Cookbook
21- https://github.com/vaquarkhan/storyteller-microservices
22- https://github.com/vaquarkhan/microservice-security
23- https://github.com/vaquarkhan/microservices-demo
24- https://github.com/vaquarkhan/spring-cloud-microservices-ELKStack
25- https://github.com/vaquarkhan/event-stream-processing-microservices
26- https://github.com/vaquarkhan/FraudDetection-Microservices-gemfire
27- https://github.com/vaquarkhan/microservice-sampler
28- https://github.com/vaquarkhan/microserviceApplication
29- https://github.com/vaquarkhan/Microservices-With-Spring-Student-Files
30- https://github.com/vaquarkhan/spring-boot-netflix-microservice-demo
31- https://github.com/vaquarkhan/spring-netflix-oss-microservices
32- https://github.com/vaquarkhan/rest-microservices
33- https://github.com/vaquarkhan/cloud-native-microservice-strangler-example
34- https://github.com/vaquarkhan/microservices-SpringCloud-netflix
35- https://github.com/vaquarkhan/knowledge-driven-microservice
36- https://github.com/vaquarkhan/event-driven-microservices-platform
37- https://github.com/vaquarkhan/devnexus-microservice-sample
38- https://github.com/vaquarkhan/microservices
39- https://github.com/vaquarkhan/Spring-Microservices
40- https://github.com/vaquarkhan/bootiful-microservices
41- https://github.com/vaquarkhan/vk-microservices-with-spring-cloud
42- https://github.com/vaquarkhan/cf-SpringBootTrader-microservice
43- https://github.com/vaquarkhan/Refactor-monolith-to-microservices
44- https://github.com/vaquarkhan/microservices-dashboard
45- https://github.com/vaquarkhan/microservice-camel-in-action
46- https://github.com/vaquarkhan/cloud-native-app-microservice-labs
47- https://github.com/vaquarkhan/spring-boot-8-microservices
48- https://github.com/vaquarkhan/building-microservices
49- https://github.com/vaquarkhan/spring-doge-microservice
50- https://github.com/vaquarkhan/microservice-service-registration-and-discovery
51- https://github.com/ewolff/microservice
52- https://github.com/semplify/Reactive-Microservice-Training
53- https://gitlab.com/training-microservices-2018-06
54- https://github.com/vaquarkhan/train-ticket
55- https://github.com/cer/event-sourcing-examples
56- https://github.com/finn-no/Docker-and-Microservices
57- https://github.com/nielskrijger/auth-server
58- https://developer.github.com/v3/repos/
59- https://github.com/vaquarkhan/ftgo-application
60- https://github.com/IBM/GameOn-Java-Microservices-on-Kubernetes

Microservices-Anti-Patterns

Alt Text

Noabouturl
1Don’t Build a Distributed Monolith- https://www.microservices.com/talks/dont-build-a-distributed-monolith/
2In this talk from the API360 Microservices Summit in New York, June 2016, Vijay Alagarasan of Asurion explores lessons learned and anti-patterns to avoid when implementing microservices.- https://www.apiacademy.co/resources/videos/api360-microservices-summit-microservices-anti-patterns
3Microservices Anti-Patterns- https://vimeo.com/198927025
4Microservices Anti-Patterns- https://vimeo.com/118020043
5API360 Microservices Summit – Microservices Antipatterns – Vijay Alagarasan, Asurion- https://www.youtube.com/watch?v=uTGIrzzmcv8
6Stefan Tilkov - Microservices Patterns and Anti-patterns- https://www.youtube.com/watch?v=VaYmRe104HU
710 Tips for failing badly at Microservices by David Schmitz- https://www.youtube.com/watch?v=X0tjziAQfNQ
810 Tips for failing badly at Microservices by David Schmitz-https://www.oreilly.com/library/view/microservices-antipatterns-and/9781491963937/video255789.html

Article-Links

Noabouturl
1Twitter- https://developer.twitter.com/en/docs
2Facebook- https://developer.twitter.com/en/docs
3LinkedIn- https://www.linkedin.com/developers#
4Google- https://developers.google.com/+/web/api/rest/latest/activities/list
8Microservices in Practice - Key Architectural Concepts of an MSA- https://wso2.com/whitepapers/microservices-in-practice-key-architectural-concepts-of-an-msa/
9Guidelines for Designing Microservices- https://medium.com/@WSO2/guidelines-for-designing-microservices-71ee1997776c
10Microservices Resource Guide- https://www.martinfowler.com/microservices/
105 guiding principles you should know before you design a microservice- https://opensource.com/article/18/4/guide-design-microservices
11Pattern: Microservice Architecture- https://microservices.io/patterns/microservices.html
12Scaling Uber from 1 to 100s of Services- https://www.microservices.com/talks/scaling-uber-from-1-to-100s-of-services/
13tagged by: domain driven design- https://martinfowler.com/tags/domain%20driven%20design.html
14DDD - The Bounded Context Explained- http://blog.sapiensworks.com/post/2012/04/17/DDD-The-Bounded-Context-Explained.aspx
15MicroservicePrerequisites- https://martinfowler.com/bliki/MicroservicePrerequisites.html
16DevOpsCulture- https://martinfowler.com/bliki/DevOpsCulture.html
17What are Cloud-Native Applications?- https://pivotal.io/cloud-native
18JSONP- https://stackoverflow.com/questions/2067472/what-is-jsonp-all-about
19Microservices architecture style- https://docs.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices
20Microservices architecture- https://samnewman.io/talks/principles-of-microservices/
21Designing microservices: Identifying microservice boundaries- https://docs.microsoft.com/en-us/azure/architecture/microservices/microservice-boundaries
22DDD Strategic Patterns: How to Define Bounded Contexts- https://dzone.com/articles/ddd-strategic-patterns-how-to-define-bounded-conte
23Microservices- https://martinfowler.com/articles/microservices.html
24Daniel Jacobson on Ephemeral APIs and Continuous Innovation at Netflix- https://www.infoq.com/news/2015/11/daniel-jacobson-ephemeral-apis
25Versioning- https://cloud.google.com/apis/design/versioning
26Semantic Versioning 2.0.0-https://semver.org/
27RESTful API Design. Best Practices in a Nutshell.- https://blog.philipphauer.de/restful-api-design-best-practices/
28Rest API Tutorial- https://restfulapi.net/resource-naming/
29REST API Design - Resource Modeling-https://www.thoughtworks.com/insights/blog/rest-api-design-resource-modeling
30Improve time to market with microservices-https://www.ibm.com/cloud/garage/architectures/microservices?cm_sp=Blog-_-blogcta-_-ArchCenter
31Digital Applications using a Microservice Architecture-https://github.com/ibm-cloud-architecture/refarch-cloudnative

The-Sins-of-Microservices

Noabouturl
1Seven Microservices Anti-patterns- https://www.infoq.com/articles/seven-uservices-antipatterns
2Microservices Anti-patterns: It’s All About the People- https://opencredo.com/blogs/microservices-anti-patterns-its-all-about-the-people/
3The 7 Deadly Sins of Microservices- https://opencredo.com/blogs/7-deadly-sins-of-microservices/
4Microservices? Please, Don't- https://dzone.com/articles/microservices-please-dont
5How Anti-Patterns Can Stifle Microservices Adoption in the Enterprise- https://blog.appdynamics.com/engineering/how-to-avoid-antipatterns-with-microservices/

Microservice-failure-stories

A compiled list to public failure/horror stories related to microservice infrastructure.

TBD


API-Design-guidelines

  1. Build the API with consumers in mind--as a product in its own right.

    • Not for a specific UI.
    • Embrace flexibility / tunability of each endpoint (see #5, 6 & 7).
    • Eat your own dogfood, even if you have to mockup an example UI.
  2. Use the Collection Metaphor.

    • Two URLs (endpoints) per resource:
      • The resource collection (e.g. /orders)
      • Individual resource within the collection (e.g. /orders/{orderId}).
    • Use plural forms (‘orders’ instead of ‘order’).
    • Alternate resource names with IDs as URL nodes (e.g. /orders/{orderId}/items/{itemId})
    • Keep URLs as short as possible. Preferably, no more-than three nodes per URL.
  3. Use nouns as resource names (e.g. don’t use verbs in URLs).

  4. Make resource representations meaningful.

    • “No Naked IDs!” No plain IDs embedded in responses. Use links and reference objects.
    • Design resource representations. Don’t simply represent database tables.
    • Merge representations. Don’t expose relationship tables as two IDs.
  5. Support filtering, sorting, and pagination on collections.

  6. Support link expansion of relationships. Allow clients to expand the data contained in the response by including additional representations instead of, or in addition to, links.

  7. Support field projections on resources. Allow clients to reduce the number of fields that come back in the response.

  8. Use the HTTP method names to mean something:

    • POST - create and other non-idempotent operations.
    • PUT - update.
    • GET - read a resource or collection.
    • DELETE - remove a resource or collection.
  9. Use HTTP status codes to be meaningful.

    • 200 - Success.
    • 201 - Created. Returned on successful creation of a new resource. Include a 'Location' header with a link to the newly-created resource.
    • 400 - Bad request. Data issues such as invalid JSON, etc.
    • 404 - Not found. Resource not found on GET.
    • 409 - Conflict. Duplicate data or invalid data state would occur.
  10. Use ISO 8601 timepoint formats for dates in representations.

  11. Consider connectedness by utilizing a linking strategy. Some popular examples are:

  12. Use OAuth2 to secure your API.

    • Use a Bearer token for authentication.
    • Require HTTPS / TLS / SSL to access your APIs. OAuth2 Bearer tokens demand it. Unencrypted communication over HTTP allows for simple eavesdroppping and impersonation.
  13. Use Content-Type negotiation to describe incoming request payloads.

    For example, let's say you're doing ratings, including a thumbs-up/thumbs-down and five-star rating. You have one route to create a rating: POST /ratings

    How do you distinguish the incoming data to the service so it can determine which rating type it is: thumbs-up or five star?

    The temptation is to create one route for each rating type: POST /ratings/five_star and POST /ratings/thumbs_up

    However, by using Content-Type negotiation we can use our same POST /ratings route for both types. By setting the Content-Type header on the request to something like Content-Type: application/vnd.company.rating.thumbsup or Content-Type: application/vnd.company.rating.fivestar the server can determine how to process the incoming rating data.

  14. Evolution over versioning. However, if versioning, use the Accept header instead of versioning in the URL.

    • Versioning via the URL signifies a 'platform' version and the entire platform must be versioned at the same time to enable the linking strategy.
    • Versioning via the Accept header is versioning the resource.
    • Additions to a JSON response do not require versioning. However, additions to a JSON request body that are 'required' are troublesome--and may require versioning.
    • Hypermedia linking and versioning is troublesome no matter what--minimize it.
    • Note that a version in the URL, while discouraged, can be used as a 'platform' version. It should appear as the first node in the path and not version individual endpoints differently (e.g. api.example.com/v1/...).
  15. Consider Cache-ability. At a minimum, use the following response headers:

    • ETag - An arbitrary string for the version of a representation. Make sure to include the media type in the hash value, because that makes a different representation. (ex: ETag: "686897696a7c876b7e")
    • Date - Date and time the response was returned (in RFC1123 format). (ex: Date: Sun, 06 Nov 1994 08:49:37 GMT)
    • Cache-Control - The maximum number of seconds (max age) a response can be cached. However, if caching is not supported for the response, then no-cache is the value. (ex: Cache-Control: 360 or Cache-Control: no-cache)
    • Expires - If max age is given, contains the timestamp (in RFC1123 format) for when the response expires, which is the value of Date (e.g. now) plus max age. If caching is not supported for the response, this header is not present. (ex: Expires: Sun, 06 Nov 1994 08:49:37 GMT)
    • Pragma - When Cache-Control is 'no-cache' this header is also set to 'no-cache'. Otherwise, it is not present. (ex: Pragma: no-cache)
    • Last-Modified - The timestamp that the resource itself was modified last (in RFC1123 format). (ex: Last-Modified: Sun, 06 Nov 1994 08:49:37 GMT)
  16. Ensure that your GET, PUT, and DELETE operations are all idempotent. There should be no adverse side affects from operations.


REST-APIs-Design-guidelines

These guidelines aim to support a truly RESTful API. Here are a few exceptions:

RESTful URLs

General guidelines for RESTful URLs

Good URL examples

Bad URL examples

HTTP Verbs

HTTP verbs, or methods, should be used in compliance with their definitions under the HTTP/1.1 standard. The action taken on the representation will be contextual to the media type being worked on and its current state. Here's an example of how HTTP verbs map to create, read, update, delete operations in a particular context:

HTTP METHODPOSTGETPUTDELETE
CRUD OPCREATEREADUPDATEDELETE
/dogsCreate new dogsList dogsBulk updateDelete all dogs
/dogs/1234ErrorShow BoIf exists, update Bo; If not, errorDelete Bo

(Example from Web API Design, by Brian Mulloy, Apigee.)

Responses

Good examples

No values in keys:

"tags": [
  {"id": "125", "name": "Environment"},
  {"id": "834", "name": "Water Quality"}
],

Bad examples

Values in keys:

"tags": [
  {"125": "Environment"},
  {"834": "Water Quality"}
],

Error handling

Error responses should include a common HTTP status code, message for the developer, message for the end-user (when appropriate), internal error code (corresponding to some specific internally determined ID), links where developers can find more info. For example:

{
  "status" : 400,
  "developerMessage" : "Verbose, plain language description of the problem. Provide developers
   suggestions about how to solve their problems here",
  "userMessage" : "This is a message that can be passed along to end-users, if needed.",
  "errorCode" : "444444",
  "moreInfo" : "http://www.example.gov/developer/path/to/help/for/444444,
   http://drupal.org/node/444444",
}

Use three simple, common response codes indicating (1) success, (2) failure due to client-side problem, (3) failure due to server-side problem:

Versions

Record limits

Information about record limits and total available count should also be included in the response. Example:

{
    "metadata": {
        "resultset": {
            "count": 227,
            "offset": 25,
            "limit": 25
        }
    },
    "results": []
}

Request & Response Examples

API Resources

GET /magazines

Example: http://example.gov/api/v1/magazines.json

Response body:

{
    "metadata": {
        "resultset": {
            "count": 123,
            "offset": 0,
            "limit": 10
        }
    },
    "results": [
        {
            "id": "1234",
            "type": "magazine",
            "title": "Public Water Systems",
            "tags": [
                {"id": "125", "name": "Environment"},
                {"id": "834", "name": "Water Quality"}
            ],
            "created": "1231621302"
        },
        {
            "id": 2351,
            "type": "magazine",
            "title": "Public Schools",
            "tags": [
                {"id": "125", "name": "Elementary"},
                {"id": "834", "name": "Charter Schools"}
            ],
            "created": "126251302"
        }
        {
            "id": 2351,
            "type": "magazine",
            "title": "Public Schools",
            "tags": [
                {"id": "125", "name": "Pre-school"},
            ],
            "created": "126251302"
        }
    ]
}

GET /magazines/[id]

Example: http://example.gov/api/v1/magazines/[id].json

Response body:

{
    "id": "1234",
    "type": "magazine",
    "title": "Public Water Systems",
    "tags": [
        {"id": "125", "name": "Environment"},
        {"id": "834", "name": "Water Quality"}
    ],
    "created": "1231621302"
}

POST /magazines/[id]/articles

Example: Create – POST http://example.gov/api/v1/magazines/[id]/articles

Request body:

[
    {
        "title": "Raising Revenue",
        "author_first_name": "Jane",
        "author_last_name": "Smith",
        "author_email": "jane.smith@example.gov",
        "year": "2012",
        "month": "August",
        "day": "18",
        "text": "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam eget ante ut augue scelerisque ornare. Aliquam tempus rhoncus quam vel luctus. Sed scelerisque fermentum fringilla. Suspendisse tincidunt nisl a metus feugiat vitae vestibulum enim vulputate. Quisque vehicula dictum elit, vitae cursus libero auctor sed. Vestibulum fermentum elementum nunc. Proin aliquam erat in turpis vehicula sit amet tristique lorem blandit. Nam augue est, bibendum et ultrices non, interdum in est. Quisque gravida orci lobortis... "
    }
]

AWS Microservices


Spring-Cloud-for-Microservices

Alt Text

Kubernetes-for-Microservices

TBD

Spring-Cloud-vs-Kubernetes

Alt Text

Spring Cloud

Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems such as configuration management, service discovery, circuit breakers, routing, etc. It is build on top of Netflix OSS libraries, written in Java, for Java developers.

Strengths

Weaknesses

Kubernetes

Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications. It is polyglot and provides primitives for provisioning, running, scaling and managing distributed systems.

Strengths

Weaknesses

From Bilgin Ibryam Article



Mock Responses

It is suggested that each resource accept a 'mock' parameter on the testing server. Passing this parameter should return a mock data response (bypassing the backend).

Implementing this feature early in development ensures that the API will exhibit consistent behavior, supporting a test driven development methodology.

Note: If the mock parameter is included in a request to the production environment, an error should be raised.


API-Doc


Security


Serialization


Storage


Testing


Continuous-Integration-and-Continuous-Delivery


Conways-Law

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” — Melvin Conway (1967).

Conway's Law asserts that organizations are constrained to produce application designs which are copies of their communication structures. This often leads to unintended friction points.

The 'Inverse Conway Maneuver' recommends evolving your team and organizational structure to promote your desired architecture. Ideally your technology architecture will display isomorphism with your business architecture.

“Microservice,” :- “Microservice we are following mostly the domain-driven approach, the idea is to have a cross-functional team.”


Alt Text

Inspired by the coming soon....


<object data="https://www.redbooks.ibm.com/redbooks/pdfs/sg248357.pdf" type="application/pdf" width="700px" height="700px"> <embed src="https://www.redbooks.ibm.com/redbooks/pdfs/sg248357.pdf"> <p>This browser does not support PDFs. Please download the Microservice IBM Redbooks PDF to view it: <a href="https://www.redbooks.ibm.com/redbooks/pdfs/sg248357.pdf">Download PDF</a>.</p> </embed>

Alt Text

Note :