Chapter 4. REST APIs
With the data schema defined, it’s time to get into the details of exposing that data. You’ll build an API with multiple endpoints that perform various operations, such as getting all the orders or submitting new ones. This is one area of the backend where we’ll get very into the details.
To create an API that can be maintained by different developers as the team changes, you need standard conventions for the team. Standard conventions are usually outlined in a document that defines the way the team agrees to approach code implementation, ranging from everything to naming conventions to the error codes and messages used in responses.
This set of conventions will make it easier to check for deviations in PR reviews for any code changes. Your PRs are changes you submit for other developers to review before they get merged with the central code and deployed. Since there may be multiple PRs for a piece of functionality, this rule enforcement is important for maintaining code consistency across codebases.
This chapter will go over how to address this convention while actually building an API, covering these areas:
-
Working through data formatting with the frontend and other consuming services
-
Writing an example of code conventions
-
Writing the code for the interface, service, and controller for the API
-
Tracking errors with logs and custom error handlers
-
Ensuring that validation is in place
These are some of the concerns that will come up as you build ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access