Article summary
While I’m sure REST will continue to have many good uses for years to come, I’m finding myself less and less excited about using REST for new web applications. It’s a bit sad as REST once seemed like such a clean solution, but I suppose the problem set has changed over the years, and now we have some other options we can look to.
What’s so bad about REST?
You can find plenty of good discussions about why people are feeling pain with REST these days, but the most common issues are:
- As applications become increasingly complex, pages can require more and more REST requests to resolve the data needed to render a page. HTTP requests are not well suited to grabbing the very small chunks of data that often make up resources, so building and transferring all these small requests can become a performance problem, especially for mobile clients.
- When new clients are written, they will inevitably need slightly more data for a resource, or slightly less data, or slightly different data. To handle these different requirements, either clients must load more data than they need, pass an increasingly cryptic set of parameters to each request to specify exactly what they’re looking for, or your API must support more and more client versions. Not great options. There’s also a built-in communication and coordination problem here if your client teams are separate from the folks building the API.
- As new client versions are released, old versions may start to break if data has been removed or relocated. For folks who release updates frequently, this can mean a very large number of client versions in the field to support.
- Developers are sick of writing and testing yet another endpoint for every piece of data. So many endpoints!
So, generally, what we want to be able to do is to easily batch requests to the server and allow each client to specify what data it wants and in what shape.
Some New Approaches
We’ve recently built our own query languages for some projects to provide clients the ability to describe the data they need, but now there are some larger players releasing more comprehensive libraries to address the problem space. Netflix has released Falcor with JSONGraph, and Facebook’s Relay and GraphQL approach is quite interesting.
Om, the Clojurescript interface to Facebook’s React, is adopting Datalog queries as the language for clients to describe the resources they need. Each Om component specifies the shape of the data it requires, allowing the framework to build the full data query for the page and populate the views with just the information they need. If you’re interested in hearing more about this approach, the Om author—David Nolen—will be at Software GR on October 27th to discuss the implementation details and tradeoffs. David Nolen is also the lead Clojurescript developer and the author of the popular clojure libraries core.async and core.logic.
A lot of these issues *do* have approaches/solutions to address them:
* HTTP/2 mitigates a lot of the problems with large number of requests for fine grained resources. It also lets you specify prefetching to help alleviate these issues.
* Use of hypermedia and sane versioning at the media type or profile level can help avoid issues with client-server version issues.
* You can use strategies such as a Prefer header with the ‘representation’ parameter, or content negotiation based on profile to tailor your representations to meet the needs of varied clients
Almost all of the above requires *work* to do right, but if you have specific needs for your clients concerning longevity, supporting a variety of versions of clients, etc, there’s nothing to say that RESTful approaches no longer work.
Sure more work creating more boilerplate code, more control checking, more twisted processes…
in brief put more burden on human shoulders.
I come from an era where machine costs were so high that human hours spent on
splitting hairs to optimize the computer’s time did not count.
Now we have all this hardware sitting around and we continue to spend time spliting hairs even more.
Having done a few apps with REST I agree, let it die. The same for micro-services, huge potential for a mess here.
Ha, timely article as I’m writing my bazillionth endpoint with a bazillion more parameters for the bazillionth tiny tweak a client needs on their dashboard, and thinking, there’s got to be a better way.
I do worry though that, while this approach could help maintain backwards compatibility in the short-term, it could get to be a nightmare in the long term because now rather than merely a *long* list of things that need to remain compatible, now you’ve got an *infinite* one.
Is it really REST that are the target here? To me it seems more like that object based contracts are the problem? Although many developers never thought about possibilities beyond predefined typed objects. ;-)