| I agree with some of this - I've never found value in the different PUT/PATCH/etc verbs, and I think the lack of examples of good "pure" REST APIs indicates that pure REST doesn't work easily for most projects. I do think this throws away some pieces that are really valuable though: 1. URLs for concepts are a good idea 2. Distinguishing between read-only operations (which can be cached) and write operations using GET and POST verbs is useful Personally I've found myself settling on "REST-ish" JSON APIs: - Every domain concept has a URL, and a standard consistent JSON representation that's also returned by list endpoints - GET for read operations, POST for anything that performs a write - I don't like content negotiation via the Accept header, so instead if I need to support alternative representations I'll do that using file extensions, .json vs .csv for example |
GET for read, POST for write. And a url made of a slash-terminated "resource" followed by an "action" verb. user 123 + edit = "/user/123/edit" ; user 123 + default(show) = "/user/123/" ; list of users = "/user/list" ; etc.
When applied to web pages, it means you can have <form action="edit"> and the "action" attribute of the form directly matches the "action" of the backend/router/API. I like that, it makes me feel warm and fuzzy. :-)