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.