3 ms·
Hi Pete, When I read your comment, I'm left with the distinct impression that we agree on 90% of what you're saying. Of course you're going to document your A
by mfenniak 13y ago
Hi Pete,
When I read your comment, I'm left with the distinct impression that we agree on 90% of what you're saying.
Of course you're going to document your API and define the format of what comes back from your requests. An API is a contract. Yeah, you isolate complexity in your API. You design an API, which is a difficult job, rather than just saying to your user, "here's a mapping to my database, do whatever you want with it."
This article does not say that APIs "should be vague about what they provide." It says the opposite, they should be very specific about what they provide.
You design an API by providing specific tools for your users. You give them hammers, not chunks of metal that they can mould however they want. You don't throw "features" into your API, you provide capabilities that your users need.
Mathieu
- Kesty 13y agoI think it depends on why you are making the API. If the intent is to publicize your business by letting other programmers integrate their app/website with your service then I agree with designing an "API" that way. Because you don't want people to do with your API things you didn't intend them to do. If the intent is to give other programmers the ability to work with your data and create their own thing using your service then the API need to be more flexible and be able to give more freedom possible to the users.