Book Image

RESTful Web API Design with Node.js - Second Edition

By : Valentin Bojinov
Book Image

RESTful Web API Design with Node.js - Second Edition

By: Valentin Bojinov

Overview of this book

In this era of cloud computing, every data provisioning solution is built in a scalable and fail-safe way. Thus, when building RESTful services, the right choice for the underlying platform is vital. Node.js, with its asynchronous, event-driven architecture, is exactly the right choice to build RESTful APIs. This book will help you enrich your development skills to create scalable, server-side, RESTful applications based on the Node.js platform. Starting with the fundamentals of REST, you will understand why RESTful web services are better data provisioning solution than other technologies. You will start setting up a development environment by installing Node.js, Express.js, and other modules. Next, you will write a simple HTTP request handler and create and test Node.js modules using automated tests and mock objects. You will then have to choose the most appropriate data storage type, having options between a key/value or document data store, and also you will implement automated tests for it. This module will evolve chapter by chapter until it turns into a full-fledged and secure Restful service.
Table of Contents (12 chapters)
RESTful Web API Design with Node.js - Second Edition
Credits
About the Author
About the Reviewer
www.PacktPub.com
Preface

API versioning


It is an inevitable fact that all application APIs evolve. However, the evolution of public APIs with an unknown number of consumers, such as RESTful services, is a sensitive topic. As consumers may not be able to handle the modified data appropriately and there is no way of notifying all of them, we need to keep our APIs as backward-compatible as possible. One way to do so is to use different URIs for different versions of our application. Currently, our contacts API is available at /contacts.

When the time is right for a new version, for example, Version 2, we need to keep the previous version available at another URI for backward compatibility. I would use /v1/contacts/or contacts?version=1 and keep /contacts mapped to the latest version. Thus, requesting /contacts will cause a redirect to /v2/contacts or contacts?version=2 and will make use of the HTTP 3xx status codes to indicate the redirection to the latest version.

Another option for versioning would be to keep the URI...