Book Image

Hands-On RESTful API Design Patterns and Best Practices

By : Anupama Murali, Harihara Subramanian J, Pethuru Raj
Book Image

Hands-On RESTful API Design Patterns and Best Practices

By: Anupama Murali, Harihara Subramanian J, Pethuru Raj

Overview of this book

This book deals with the Representational State Transfer (REST) paradigm, which is an architectural style that allows networked devices to communicate with each other over the internet. With the help of this book, you’ll explore the concepts of service-oriented architecture (SOA), event-driven architecture (EDA), and resource-oriented architecture (ROA). This book covers why there is an insistence for high-quality APIs toward enterprise integration. It also covers how to optimize and explore endpoints for microservices with API gateways and touches upon integrated platforms and Hubs for RESTful APIs. You’ll also understand how application delivery and deployments can be simplified and streamlined in the REST world. The book will help you dig deeper into the distinct contributions of RESTful services for IoT analytics and applications. Besides detailing the API design and development aspects, this book will assist you in designing and developing production-ready, testable, sustainable, and enterprise-grade APIs. By the end of the book, you’ll be empowered with all that you need to create highly flexible APIs for next-generation RESTful services and applications.
Table of Contents (13 chapters)

RESTful API advanced patterns

We covered few critical RESTful patterns in the earlier chapter; now it's time to get into more advanced patterns and get our hands dirty to provide our customers and app developers with the best-possible RESTful services implementation. Let's start learning how to implement versioning for our services.

Versioning

Many books and articles recommend avoiding versioning APIs if possible. However, it's not practical to believe that we'll develop one API that caters to almost every requirement within the first release and never changes, so we avoid versioning altogether. A few others recommend providing different URIs for different (major) version changes. Ideally, we'd manage...