Let's summarize what we have covered in this chapter and what we can take away in the context of the REST architectural style. We started with a brief history of the evolution of the World Wide Web, its layers, and its architecture. Then we moved on to the web API, a development model for web services, and how REST-based services communicate with existing web protocols with simplified representations.
We looked briefly at SOA and also in more detail at ROA. We covered the purpose of ROA (to use simplified, well-understood and well-known web technologies along with core design principles), its principles, and its characteristics as well. After setting the ground with ROA, we got introduced to the concept of REST; the mandatory constraints of REST architecture, such as client-server, statelessness, cacheable, uniform interface, and layered systems; and also the optional code on demand constraints.
As part of a uniform interface, we learned its four guiding principles, which are the identification of resources, manipulation of resources, self-descriptive messages, and HATEOAS, and we also touched upon the importance of the RMM to get a foundation for building RESTful services.
This chapter described in detail the five mandatory constraints and how in Roy's view they define an architectural style as RESTful. It is critical to understand what makes REST RESTful and what does not.
We concluded this chapter with a quick introduction to the software architecture properties of the WWW, and how REST constraints help to achieve the architecture goals of REST, such as performance, scalability, and simplicity.
I hope you have enjoyed this chapter. In the next chapter, we will learn about API design strategies, such as self-service enablement, resource collaboration, and how to address security and scalability concerns along with RESTful API guidelines and constituents.