Let's think about who the consumers of any web service APIs are. Will it be another system, another software application, or an end-user? Mostly, the consumers of the APIs are another software application or another system itself. So, we can conclude that the customers of any API will be the app developers who give life to the software make it purposeful and usable by their programming codes. So the APIs are heavily dependent on the application developers or app developers.

So application developers should be the primary focus of API design, and for them to consume the APIs, there should be defined and accessible business functions. Please do remember that without any application developer or app developers ready to use the API, the API will cease to exist.

The following is a list of best practices used by API designers to produce APIs that app developers like to use:

• Keep APIs simple and easy to use—simplified, friendly, and intuitive APIs always attract APP developers (clients for our API), get the best out of the APP developer, and make the APP developer's life more comfortable, less painful, and more productive.
• Expose well-defined and instantly recognizable business functions.
• Make APIs accessible with any standard web browsers—exposing APIs with existing web infrastructure (HTTPs GET, POST, PUT , and DELETE) and so accessible through a standard browser makes underlying APIs platform independent.
• Abstract service internals and domain models—the best APIs expose only URIs and payloads and not the service internals or domain models. An example is https://www.googleapis.com/books/v1/volumes.
• Ensure RESTful API payloads don't have any traces of SOAP payloads as the clients are not the same (machines versus humans).
• Be consistent—API implementations should be free from variation or contradiction; carry consistency across APIs by setting clear standards to help consumers with what to expect from the API, and implement similar behaviours such as searching and filtering (or pagination and limits) in the same way.
• Implement the standard URL pattern—an example of the standard URL pattern is /collection/item/collection/item , and the /collection can be books, dogs, events (plural), and so on.
• Exercise standard terminology—following standard and meaningful elements in the URI is critical for API success. An example of standard terminology would be bookId, dogId and eventId, and not bId, dId and eId.
• Be flexible—APIs are flexible to accept input from clients. An example would be /planner/v1/tasks or /planner/v1/Tasks or /planner/v1/TASKS; lowercase, uppercase, or camel case in the preceding example should be acceptable and should behave in the same way.
• Be stable—incremental modifications to the APIs are inevitable, but it should be independent of the client applications. In other words, no forced amendments to the clients who consume the APIs that undergo modifications. Say, /books/v1/volumes involves no changes to the clients and provide additional benefits/defect fixes when the volume module goes through some changes.
• There should be a clear handle for errors and error messages—API implementations shouldn't just provide better business functions; it is critical that it handles the errors and error messages well to help clients with useful and human-readable error messages, including diagnostic information that can be understood by the app developer, as error messages give hints and assist the APP developers to resolve issues that may otherwise result in an error.
• Documentation—APIs are discoverable and documented, so publishing the API documentation is a must. API documentation includes a getting-started guide, sample codes, sample requests, sample responses, sample implementations, elaborate explanations about authentication and error handling, information about feedback avenues, and so forth.
• Provide feedback and support mechanism for API users.

Would it be good to have API design practices so you can jump-start the API design? No, not yet. We need to get to know about a few core API design principles, which we will review next.