> Whenever you evaluate an API, or create a new one, you must always, always, ALWAYS start by writing some code as if you were a user trying to do the thing tha

> Whenever you evaluate an API, or create a new one, you must always, always, ALWAYS start by writing some code as if you were a user trying to do the thing that the API is supposed to do. I’ve been telling this to the developers I have worked with for the last 15 years. Similar to Amazon’s “working backwards” concept, the only way you can reliably get a good API is to engineer it from the customer’s point of view. That means write the code that you want your customers to write (or that you would want to write, if you were the customer) and then engineer backwards from that. One of the biggest problems with API design is that often the developers of the API have a vastly different mental model of the functionality that they’re encapsulating in an API, than their customers. Often, customers can’t even develop that mental model because the encapsulated code is a black box. Another common API design problem is that you’ll just write a simple CRUD API around your object model. This often causes customers to have a bad experience if they use objects in conjunction with each other, and have to do a lot of housekeeping to associate objects with each other and keep track of multiple objects to perform simple tasks. My example here is AWS Route 53; the API is a real pain to use if you just want to do something simple.