Part 3 Constrained API design

We have designed a versatile, user-friendly, interoperable API that does the right job, streamlines consuming application development, makes developers feel fantastic, and enhances the end-user experience. However, this API design may be unrealistic and require adaptation to potential constraints. We must consider data and operation exposure and access, such as whether account reads should return sensitive information like payment card numbers, and who can read a specific account in a Banking API. We must avoid creating an API design that causes an excessive infrastructure load or drains smartphone batteries. We must integrate into our design the nature and usage of our data, the infrastructure, and business limitations: for example, we won’t treat files like regular data, and the system or business may not be available 24/7. Finally, modifying an existing design involves caution; careless modifications risk making existing consumers crash, preventing our or our consumer’s end users from accessing our services.