4 ms·
No, not trolling. The vast majority of API providers do provide libraries (of course, none of them "force" you to use them, and nor will we), and this is consi
by faxman 15y ago
No, not trolling.
The vast majority of API providers do provide libraries (of course, none of them "force" you to use them, and nor will we), and this is considered good practice in many places (see for example the recent "Designing Great API Docs" at https://news.ycombinator.com/item?id=3453315 https://news.ycombinator.com/item?id=3453315).
I understand the purism of doing it the REST way, but if in practice most developers end up using a library which abstracts away REST - that's what prompted my original question.
- toyg 15y agoYeah, a library for a library, there's little difference, I agree; but the main point of REST is exactly the fact that the library is optional, and if necessary it can be entirely bypassed with little effort. With SOAP this is almost invariably impractical or impossible; you'll need a basic SOAP library even for sending "Hello world" back and forth. REST is more human-friendly in many ways. Somebody could also say REST implementations usually end up passing less data around, because they usually don't require the overhead of compulsory metadata typical of SOAP standards (schemas, "envelopes" etc). This is obviously a trade-off with "exactness", but again most developers are happy to trade speed for metadata they'll rarely use (if ever). It also helps making server-side caching easier.
- faxman 15y agoOK, thanks. Going back to the drawing board with renewed vigor!