At a major telco company in Belgium we have designed and implemented a cutting-edge architecture using microservices and hypermedia (REST level 3 / hateoas) for the entire customer- and business-facing web portfolio. Throughout this session you will learn what the microservices hype is all about, including its benefits and pitfalls based on our experiences of running microservices (including the Netflix OSS) in production at a major company in Belgium. To manage hundreds of microservices you need to apply certain patterns such as circuit breakers, gateways, service registries and so on. You will learn how these patterns work, how they are applied through the Netflix stack and how easy it is to use them in your architecture through code examples and demos. The contracts between these microservices should be well defined and loosely coupled. Using hypermedia as the engine of application state (hateoas), we can benefit from independent evolution and decoupled implementation. How we can implement these using Spring Hateoas, correctly document using Spring Restdocs, integrate with the HAL browser and version using JsonViews will become clear in the second part of this session.
4. @andreasevers
Benefits
• Small, easy to understand code base
• Easy to scale
• Easy to throw away
• Easy to deploy
• Ability to use a different technology stack
• Smaller teams
• System resilience
6. @andreasevers
Pitfalls
• Failing to adopt a contract-first approach
• Assuming the wrong communication protocol
• Introducing a shared domain model
• Defining inappropriate service boundaries
• Neglecting DevOps and testing concerns
• Disregarding the human factor
• Operational complexity not under control
• Failing to embrace eventual consistency
47. @andreasevers
Why Hateoas?
• Updating server-side web APIs only to learn that client applications
no longer work as expected without undergoing code updates
• Moving long-lived server applications to a new DNS name (e.g. from
www.belgacom.be to www.proximus.be) and having to completely
rewrite all of the API documentation as well as update all existing
client code with all its links to the server’s APIs
• Implementing new or modified process flow within the server-side
application and discovering that existing clients break when
encountering the new rules, ignore the rules, or, worse, continue to
execute their own code in a way that creates invalid results on the
server
54. @andreasevers
Hateoas in action
How would you explain to a client to get to the Nerd in the
Basement painting?
A. Go to Amazon.com, in the categories go to fine arts, follow
paintings, more specifically oil paintings, and click on the one
with the title Nerd in the Basement
B. Type
http://www.amazon.com/Nerd-in-the-Basement/dp/
B00L849CSS/ref=lp_6685279011_1_2?
s=art&ie=UTF8&qid=1431864368&sr=1-2 in your browser
55. @andreasevers
Hateoas in action
HTML is a hypermedia format
<a> is a link with method GET
<form> is a link with method POST (or other if specified)
The browser understands this syntax and shows a link or a form if
the server response contains these tags
56. @andreasevers
Hateoas Requirements
Communication between Client and Server depends on:
• Where does the client have to start?
• Root API
• In regular websites: the homepage
• Where am I?
• How do I interpret the current API response?
• In regular websites: the syntax of HTML is interpreted by the browser
• Where can I go?
• What does a link or form with a certain relation or class mean?
• In regular websites: link with relation “stylesheet”, form with action “login”
60. @andreasevers
Hateoas Concern: Scope
In case of one or two clients built in the same team, it is arguable
whether auto-discoverability is really a necessity
61. @andreasevers
Hateoas Benefit: Non-structural Changes
“customers/1/accounts/1/products/1234”
auto-discoverable through HATEOAS as
“customers[1].accounts[1].products[1234]”
will not break when 1234 as id is changed to “basementNerd”
62. @andreasevers
Hateoas Concern: Structural Changes
“customers/1/accounts/1/products/1234”
auto-discoverable through HATEOAS as
“customers[1].accounts[1].products[1234]”
could break when accounts are bypassed
63. @andreasevers
Hateoas Benefit: Changing the URI of a
resource
“customers/1/accounts/1/products/1234”
being returned as part as the response body of
“customers/1/accounts/1”
will not break the client
64. @andreasevers
Content Types
"text/html"
• Browsers know how to parse it
• Browsers understand keywords inside it
• E.g: a + href , form + action + method , ...
"application/json" or "application/xml“
• Clients know how to parse it
• Clients don’t understand keywords inside it
• Needs a uniform format as communication between client & server
• Needs a reference for out-of-bound (api-specific) keywords
65. @andreasevers
Content Types
• JSON
• NOT hypermedia-aware by default
• Needs a fixed format to support links and forms
• Many formats available
• XHTML
• IS hypermedia-aware by default
• Harder to process XHTML responses using javascript (xpath is required)
• The API responses can also be read by a human as regular HTML pages
• SVG, Atom, HTML
• Similar as XHTML but not preferred
66. @andreasevers
JSON Formats
• JSON-LD
• Augmenting existing APIs without introducing breaking changes
• Needs HYDRA as a vocabulary for communicating operations
• Decoupling of API serialization format & communication format
• HAL
• Minimal, light weight syntax and semantics
• Offers most of the benefits of using a hypermedia type
• Easy to convert existing API to HATEOAS
• Chosen and supported by Spring
• No support for specifying operations
• Collection+JSON
• Can list queries that your collection supports and templates that clients can use to alter your
collection
• Great for publishing user editable data
• SIREN
• Represents generic classes of items
• Supports operations
• Concept of classes, bringing a sense of type information to your API responses.
77. @andreasevers
Best practices for documentation
Write as much as possible in a format which is designed for writing
Don’t use the implementation to provide the documentation
Provide some guarantees that the documentation is accurate
h8ps://github.com/spring-projects/spring-restdocs
78. @andreasevers
Thank you for your attention
@andreasevers
https://github.com/oraj-360
http://registry.oraj360.cfapps.io/
https://netflix.github.io/
http://projects.spring.io/spring-cloud/
http://projects.spring.io/spring-hateoas/
https://github.com/spring-projects/spring-restdocs