This chapter covers:
- Transposing API goals into a programming interface
- Identifying REST resources and actions and mapping those
- Designing API data from concepts
- Differentiating REST APIs and the REST architectural style
- Why the REST architectural style matters for API design
In the previous chapter, you learned how to identify an API’s goals—what users can achieve using it. For a Shopping API, some of these goals could be search for products, get product, add product to cart, check out cart, or list orders. These goals form the API’s functional blueprint that we will use to design the actual programming interface that is consumed by its users (developers) and their software. To design this programming interface, we will transpose these goals and their inputs and outputs according to an API style as shown in figure 3.1.
Figure 3.1. REST programming interface for the get product goal
REST stands for Representational State Transfer. Here, the REST API style transposes the get product goal into a programming interface. It is represented by a GET /products/{productId} request, where productId is an input parameter (here its value is P123), and a 200 OK is a response with some output data consisting in the reference, name, and price properties. How do we design such a programming interface?