Hacker News Reader

Comment by bitcrusher | Hacker News Reader

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.

View on HN

Couchdb 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

It'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.

I have yet to see a crystal clear definition of REST. Where would be the best one you have found?

REST is a set of constraints for building a system. A RESTful interface is one that cleanly abstracts the underlying data store into one that is simple to use for third party systems.

It's important to understand that a RESTful system doesn't necessarily expose a true model of the underlying data store. You could have an invoicing system that contains Customer and Invoice models. I see developers confusing that to mean "you have /customer/ and /invoice/ endpoints and never the twain shall meet". If you need to embed customer details into invoices and/or invoice details into customers, then feel free to do that if it makes sense for your application.

There's more to it than that, and I've mostly just described how common HTTP-based RESTful systems work. Fielding gave a lot more detail in his thesis: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...

I'd recommend reading it, as it helps clarify a few things. Also read up on the term HATEOAS, which details how information should be interlinked where possible, so your system can be (theoretically) crawled for more information.

I 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.

It's a style, not an implementation. Highly opinionated definitions are the norm for REST.

It is defined very clearly. The fact that most developers don't know what it is does not mean REST is a subjective style.

For 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).

You 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...

His 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.

I'm not sure if the author is even aware of the 202 status code, which seems to solve this and other asynchronous issues.

Perhaps the client would poll a response if everything was truly async?

Reply on news.ycombinator.com