This via r/programming today: A collective list of free APIs for use in software and web development.
This via r/programming today: Recommended Pagination for APIs. Keyset pagination is an approach I’ve seen recommended a fair bit lately…
Today via Lobsters: Write code that is easy to delete, not easy to extend. I think I like programmingisterrible.com.
Today I stumbled upon Microsoft REST API Guidelines.
I also must confess to a strong bias against the fashion for
reusable code. To me, “re-editable code” is much, much better
than an untouchable black box or toolkit. I could go on and on
about this. If you’re totally convinced that reusable code is
wonderful, I probably won’t be able to sway you anyway, but
you’ll never convince me that reusable code isn’t mostly a
— Donald Knuth, Interview with Andrew Binstock
An interesting approach to testing web services: A logical way to test online software.
I just wanted to get something that I’ve thought for many years on record, because I don’t think I’ve ever had the chance to discuss it much before, but I believe JSON web services (“REST APIs”) and web applications should deal only in two HTTP verbs, being: GET and POST. You use GET for queries and you use POST for submissions. All POST operations go through business logic for particular services and CRUDing URLs is a supremely bad idea, in my opinion. Just wanted to get that on record. Thanks. p.s for web applications you should 3xx on success, not 2xx on success; what you do for JSON web services is up to you, but for those 2xx is probably fine.
Over on the StackOverflow blog: Best practices for REST API design. Some of it is good but I disagree with a bunch of things. I made some notes:
* Use singular https://www.example.com/comment/list Not: https://www.example.com/comments * Use multidimensional selectors, not path/hierarchical selectors: https://www.example.com/comment/list?artist=nirvana&album=nevermind Not: https://www.example.com/album/nirvana/nevermind/comments * Use noun/verb format: https://www.example.com/comment/list https://www.example.com/comment/register https://www.example.com/comment/edit/54688 https://www.example.com/comment/view/54688 https://www.example.com/comment/reply/54688 * The [ noun, verb ] pairs map to Facilities for implementation: [ comment, list ] => CommentLister [ comment, edit ] => CommentEditor [ comment, view ] => CommentViewer Facilities have submit/render functionality and round-trip view state. * HTTP success 30x's not 2xx's. * Include a 'submission ID' on <form> elements for idempotent operations * GET and POST only, don't CRUD URLs, rather invoke business processes
A fun read: Falsehoods Programmers Believe about REST APIs.
Today I discovered Library Writing Realizations which has a bunch of things to think about when designing APIs.