The implementation for production has similar constraints as the prototype implementation described in the previous section. The implementation needs to conform to the API description and needs to be delivered as quickly as possible. In addition, the API is fully integrated into the API portfolio. The goal of properly engineering software systems is to ensure not only the correct functional aspects but also the correct non-functional aspects. Some of the most important non-functional aspects of APIs are security, performance, and availability.
When an API has reached this phase of the approach, the API description has been properly designed, has gone through several feedback loops has been verified from several perspectives. The API description should thus be stable. Just as in the previous phase, the stable and verified API description is used as a blueprint for automatically generating an API implementation skeleton. Automatic code generation ensures that the implementation is consistent with the API description, and thus is consistent with all the design decisions the description embodies.
However, the generated code is merely a code skeleton. The behavior of the API needs to be implemented manually, by filling in the gaps of the code skeleton. In the previous phase, the feasibility of the implementation has been shown, critical aspects of the implementation have already been tested and many insights have been gained. These insights are now applied during the implementation phase.
The focus of the implementation in this phase is thus, the proper engineering of the API. Proper software engineering practices need to be used. For example, common patterns should be identified, factored out into libraries, so they can be reused across the API portfolio.
The non-functional requirements for production systems are much tougher than for prototypes. The security of the API needs to be ensured. This can be achieved by choosing and enforcing adequate security mechanisms. The availability and performance of the API need to be ensured. These properties can be ensured by applying rate limitation and caching.
Verification: Acceptance Tests with Pilot Consumers
The set of pilot consumers typically grows as the API matures. The first group of pilot consumers used in the prototyping stage may consist of internal consumers of the API provider. As the API matures, the set of pilot consumers may evolve into a number of hand-picked API consumers.