12 ms·
You cannot build a large API effectively without using it. Programming is tons of details, and you're going to miss some if you aren't programming with your AP
by olau 9y ago
You cannot build a large API effectively without using it. Programming is tons of details, and you're going to miss some if you aren't programming with your API yourself. It's like building a graphical user interface without ever firing it up.
For instance, if you build a simple REST interface with a list at /object/ and details at GET /object/1 and changes at POST /object/1, then you're good, right? This is a well-understood way of structuring things?
Well, what if your objects are really simple and someone has to synchronize 100k of them. It's not possible to do that efficiently through such an interface.
The API has to see some use, and it has to be able to evolve as you learn. And you need to be ready to make some sacrifices on your side of the fence, to make the life of the API user easier.
- habosa 9y agoThis. I work in Developer Relations and we used to say our motto was to be the "0th customer". Just by building on top of new APIs we planned to release we'd discover piles of issues and improvements that even the best developers can't spot in the design phase.
- crdoconnor 9y agoThis is essentially the argument behind BDD, except applied at a level where the 'customer' is another developer. Some of the worst APIs I've seen have been ones designed by a backend developer based upon some vague specifications handed down by a non-technical PO. They were often designed with half of the stuff that was necessary missing, lots of stuff that wasn't necessary and some stuff which made no sense before being thrown over a wall. The better APIs were 'designed' by the developer who would write the code that would consume them. Even if that just meant an email or a scrap of paper with a few example URLs and snippets of JSON.