Facebook Relay: An Evil And/Or Incompetent Attack on REST

"REST" as we've come to know it is just a useful design pattern for APIs. That's it. It's not a law. You probably don't lack understanding of REST, every developer just has their own interpretation of edge cases (multi-resource responses, etc.) and different experience with what's worked and what hasn't.

I wouldn't get caught up in the details. Use whatever tool is appropriate to solve your problem(s). I think it's likely we'll find certain design patterns (GraphQL vs. REST) are best suited to projects with specific problem spaces or scope. Maybe it's always best to start out "RESTful" and begin migrating to a different interface as your app scales in complexity. Maybe the latter problem is only an issue with medium or larger projects. Perhaps it's best to teach developers to be strict with REST to develop good habits and start migrating away once they're confident and comfortable with their ability to make architectural decisions.

Either way --- don't sweat it. Experiment with what you like because you're the creator. Figure out what works best for you, and you'll be able to identify wins and challenges and decide for yourself how to use the technologies around you and what they bring to the table.

How did this article get flag killed?

I wanted to say something constructive about the topic: Any time you layer an arbitrary UX over a given data model, expressiveness is absolutely necessary in the protocol in order to minimize round trips. This is why SQL has been so successful on the server side.

An alternative to the "moving the whole graph to the client side" approach is the intercooler.js way [http://intercoolerjs.org/]: HTTP requests express UI/UX needs, rather than generalized data queries to support a client-side object graph and model.

This eliminates a whole swath of complex issues that come up with managing multiple instances of data in a distributed object graph environment, knocking system complexity down an order of magnitude.

Interesting how this article was #1 on HN a few hours ago and mysteriously disappeared.

Conspiracy?

The versioning section of the article made absolutely no sense to me. Yes, HTTP has a mechanism to encode version info. He completely ignores Facebook's claim that dealing with that complicates server side code (because it has to distinguish between different versions), but goes on a rant that because they don't understand that the protocol allows to encode this (why ever Facebook's developers wouldn't realize this) they don't understand REST. No answer to how this magically makes the server side easier, completely ignoring what I think is the argument.

And really, most of that article feels like this. His facts are not wrong, but they don't match the claims they supposedly refute. Or if they do occasionally, it is drenched in so much rant-sauce that it gets covered up.

> people spend so much time debating what is and what isn't REST should be a red flag that maybe it isn't the answer to everything

Does not follow. People spend so much time debating what is and what isn't REST because there are a great number of people who do not understand the topic, have no actual interest in learning it properly, and then come to wrong conclusions and start making wildly inaccurate arguments.

Not all Web application problems can be cleanly modelled over REST, so indeed it is not the asnwer to everything, but most can. For those that can, using the REST architectural style is more advantageous than, let's say, remote-procedure calling.

> All the simple REST examples make it look like it is the perfect solution for CRUD tasks.

All the simple REST examples are written by those ignorants I mentioned above. The simple CRUD model falls apart when there is just a little more complication involved. REST does not mean just CRUD, as any decent REST book teaches.

> If the server returns 404 for a resource, what actually happened? Did the web server or my application return the 404.

⁇ If the server returned 404, the server returned 404. This means the client application/the user agent made a mistake, indicated by the leading digit 4.

> Conflating HTTP and application error codes leads to confusion.

When following REST, that conflating is actually a good practice. Not doing so means tunnelling a proprietary, possibly ad-hoc protocol over HTTP, resulting in non-interoperability. There is no need for any confusion, the response body can deliver a precise problem description applicable to the concrete error condition, perhaps even giving an indication how to fix the problem. There is a wealth of status codes " rel="nofollow">https://github.com/for-GET/know-your-http-well/blob/master/s... and many of them semantically map to typical application error states, and it's okay to fall back to generic codes like 422 or 400.

> HATEOAS is just superfluous. […] I just haven't found a practical use for it.

You need to bring a better argument to the table. Establishing relations between and traversing resources using links and other hypermedia controls is central to the REST architectural style. Every Web browser does this, for timbl's sake!

> REST encourages creating a CRUD interface for every single resource.

Not true. Nothing in REST encourages this. It's the software architect's fault if there are 100 (supposedly underutilised) resources, not the fault of the architectural style.