3 ms·
Still digesting this, but it doesn't pass the smell test. There are too many assumptions that are just plain... wrong. For example: There seems to be an impli
by bitcrusher 13y ago
Still digesting this, but it doesn't pass the smell test. There are too many assumptions that are just plain... wrong.
For example:
There seems to be an implicit assumption that all of the REST endpoints are just maps to CRUD operations. Perhaps for the most barebones, basic API this is true, but service APIs are more than just CRUD ops. They're abstracted interfaces to a complex series of tasks (for the sake of argument, we'll call them 'orchestrations' ). Just because you're doing a "POST" to /user/foo doesn't mean that the service is only doing a simple insert. It might be looking up similar users, sending out notifications, validating data, de-duping, etc.
The more I think about this the less sense it makes. Perhaps I'm missing something.
- wisty 13y agoYou can do this by adding all the logic to the database. The author is a CouchDB fan. There's pros and cons to this approach. It's not a new idea - see http://stackoverflow.com/questions/1473624/business-logic-in-database-versus-code http://stackoverflow.com/questions/1473624/business-logic-in...
- staticvar 13y agoHis post does focus mostly on CRUD. Personally I usually proxy CouchDB to a path in my REST API for handling CRUD and then proxy in the rest of my services at other paths. In the case of doing a write and then some other operation, the CouchDB folks usually write a process that listens to the changes API which then triggers the desired other operations.
- platz 13y agoPerhaps the client would poll a response if everything was truly async?
- ollysb 13y agoCouchdb lets you listen to changes[1], if you want to do anything in addition to the basic CRUD you can do it there. This does limit you to performing asynchronous operations but most of the time that's good enough. You do still end up with a scaling issue but because the users aren't hitting that part of your system directly it's easier to spread the load over time. [1] http://guide.couchdb.org/draft/notifications.html http://guide.couchdb.org/draft/notifications.html
- batbomb 13y agoI'm not sure if the author is even aware of the 202 status code, which seems to solve this and other asynchronous issues.
- protonfish 13y agoIt's clear the author doesn't understand REST - he thinks that it is a dumb wrapper over a relational database. It's not surprising that straw man burns so well.
- BenoitP 13y agoI have yet to see a crystal clear definition of REST. Where would be the best one you have found?
- kordless 13y agoIt's a style, not an implementation. Highly opinionated definitions are the norm for REST.
- protonfish 13y agoIt is defined very clearly. The fact that most developers don't know what it is does not mean REST is a subjective style.
- ChikkaChiChi 13y agoFor the sake of brevity and callback, I'll say it's a SMART wrapper over a backend service or services (commonly at this point, a relational database).
- protonfish 13y agoI think the best definition is in Fielding's thesis where he lists the 4 REST interface constraints: 1) Identification of resources 2) Manipulations through representations 3) Self-descriptive messages and 4) HATEOAS. 1 & 2 mean that you should name a resource something for identification only and that name should be used no matter what you are doing to it. In HTTP you use a combination of verbs and request body data to tell the server what to do with a resource. HTTP implements #3 though status codes including verbose descriptions in the response body. HATEOAS (Hypermedia as the engine of application state) means that 100% of functionality must be accessible through a browser.
- 13y ago