4 APIs: The piping between our components
This chapter covers
- An introduction to the FastAPI framework
- Documenting APIs using the OpenAPI standard
- Testing our APIs using Postman and Locust
- API management with WSO2
In this sprint, we work on another research spike where we explore designing and testing application program interfaces (APIs). An API is simply a way to interact with a software component. Regardless of whether we are dealing with microservices and distributed systems or using packages from npm/pip, we utilize APIs.
4.1 API-driven design
Generally, when we mention APIs in this book, we are talking about the REST (Representational State Transfer) API standard. However, there are other standards as well, such as GraphQL and the older SOAP (Simple Object Access Protocol). We may also come across message queuing, such as IBM Websphere MQ and RabbitMQ. Table 4.1 shows some pros and cons of the more common approaches to implementing APIs.
Table 4.1 Pros and cons of different APIs
| REST |
SOAP |
GraphQL |
|
| Pros |
Simple; builds on standard HTTP methods Multiple data formats can be supported, although JSON is the most common. |
Relies on XML-based messaging Enterprise-level security |
Efficient Single endpoint Strongly typed |
| Cons |
Versioning and breaking changes can be complex to manage. The number of endpoints may become inconvenient. |
Complex to implement Wordy XML-based messages |
Steeper learning curve |