RESTful hypermedia APIs: Useful or not?
Many of the known public web APIs claim to be RESTful but, in reality, many APIs do not fulfill an important element of REST: Hypermedia as the Engine of Application State (HATEOAS). In this session from JAX London 2017, Kai Tödter gives an introduction into this topic and provides concrete examples on why RESTful Hypermedia APIs are useful.
RESTful web services have been around for quite some time and are very popular. Many of the known public web APIs claim to be RESTful. However, many APIs do not fulfill an important element of REST: Hypermedia as the Engine of Application State (HATEOAS).
This session gives an overview of the topic and shows many concrete examples why RESTful Hypermedia APIs are useful. Kai introduces various hypermedia formats, like HAL and Siren, as well as their integration into existing infrastructures, such as the Spring Stack. He also provides practical tips for creating API documentation.
The goal of this session is that all attendees can decide whether hypermedia offers advantages for their own REST API.
Make sure you check out the interview with Kai Tödter on the advantages and disadvantages of microservices.
JAXenter: What is the biggest misconception about microservices?
Kai Tödter: I guess one of the biggest misconceptions is that microservices might solve all the existing (architectural) problems. That is definitely not the case, and teams should think carefully not only about the benefits but also about the costs when they want to go with a microservice-based approach.
JAXenter: What are the key elements in implementing a microservice-based architecture?
Kai Tödter: There are many elements that characterize a microservice-based architecture. I think one key element is that microservices are treated like products rather than projects, meaning that the team owns the whole lifecycle of a microservice, including deployment and operation. A team that owns a microservice should be cross-functional and organized around business capabilities rather than specific technologies (like UI or databases), all skills needed to implement the whole microservice should be in the team. Data management should be decentralized (e.g. each microservice decides his own persistence layer) and technology stacks should be chosen by the team, rather than having a centralized governance.
See the full interview here.