Do you think REST is still relevant for Web Apps?

Not applicable

I ran across this link, with a clickbaitish title, REST for Web Apps is So Passé. As mentioned in the article, Facebook is working on GraphQL. Netflix is also working on something similar, Falcor.

For me personally, I felt like the whole REST thing was just sinking in, and I really liked it, and then this comes along to shake things up. 🙂

I work on the Management UI, and I do notice some of the pains described in the article, e.g., query params start proliferating in the Management API to meet our needs.

I don't know if GraphQL is the answer, as you are arguably, for example, just moving the REST query params logic somewhere else.

Just curious what others think. I don't have the answers, but this article shook my RESTful worldview a little, and I'm wondering if anybody else has tried something along these lines or run into similar issues.

Charles

(Had this as an article, reposted as question)

0 8 2,482
8 REPLIES 8

Not applicable

The data transfer issue, specifically, was the reason for http/2. As for the rest... well, the more you treat your API as a generic datastore, the more you end up with the same needs as you would a database.

Can you expand a bit on how an API should be more than just a means of serving resources (to your point about datastore)?

The point just being that there is a continuum of communication styles that range from custom RPC on one end to generic data store on the other. The further you push your communication style toward the data store side, the more you need query capabilities. On the converse, the further you push your communication toward the RPC side, the more assumptions you have to make about your clients. I wouldn't argue that one is better than the other for all situations, but you do end up making different trade-offs and perhaps may need different tooling to address them.

Not applicable

Without a doubt REST is still relevant IMO. A concern I have from conversations with practitioners, customers, and thought leaders at Apigee is too many people seem to view REST as written on tablets, delivered, and therefor immutable. Rather, I think we see REST as an evolving pattern of integration. The Apigee definition of Pragmatic REST is exactly that.

Where I would like to see some thought and evolution is allowing for consumer customization of the API structure including methods of navigation in the resource model and customization of payloads themselves to the unique needs of consumers. GraphQL begins to address this but does so in a fairly heavy way. What I have envisioned is a meta resource that consumers can utilize to define structure of payloads, relationships between resources, and the like.

Rather than moving complexity from Query Parameters to a Query Syntax in the body of a request, I would see clients predefining queries (ala Stored Procedures from another life) that are based upon a canonical model that underlies the superset of the API surface. Similarly, a meta resource could be maintained by the consumer that describes the resources served by the API allowing them to optimize (say asking for a sparse representation of an Accounts resource for one use case and a verbose version for another). This essentially moves the work of customizing the exposure facade to the consumer. I have some early prototypes of this approach based on good work by @SudheerGopalam to share at some point in the future.

While, this is an incremental improvement in how we manage and serve APIs on the Apigee platform I believe it can be a means to addressing many of the sprawl issues observed in the original article.

Not applicable

GraphQL helps decouple the UI from the API, which is a good thing -- updating the API each time the UI needs a custom query is a pain and slows down UI development. Implementing flexible queries with REST is awful: see oData. Implementing them by hand with a bunch of plain REST queries, then filtering/joining client-side is inefficient and a lot of work.

I'd like to see a REST-to-REST adapter with GraphQL in the middle.

Not applicable

I Agree with the part that GraphQL seems to be moving the problem somewhere else, but sometimes solving a problem is making it somebody else's problem, for example, we don't need to deal with local optimizations based on processor architecture, that's a problem of the compiler.

Actually API Management is moving a bunch of problems to somebody else: Apigee :) I think moving the problem of specifying the response to the caller makes things more flexible. As Yegor says, using REST for complex hierarchies can be a hard experience. But it is not only about schema specification, it is also about types. Many REST services, mainly the ones based on JSON favor type problems as there is no simple way to enforce types or relationships. As you have types and they are discoverable, you have more knowledge on the client side. And because the projections are made with types instead of Tables as in a relational language, you can avoid ORM-like overheads. Yegor, I didn't get what do you mean with REST-to-REST adapter with GraphQL in the middle? seems an interesting mix of worlds, but I was not able to imagine what would it be.

Not applicable

I did not think that REST for Web Apps is So Passé was a good POST. The author seems not to know what REST is. He could have written a good POST along the lines of "why it is useful to incorporate a query capability into an API, and why REST is the right model to use to do this". Most APIs today already have a limited form of query capability, usually expressed in the query string portion of the URL. Putting the query in the URL like this means that the queries themselves (or their results, really) are themselves HTTP resources. This is one of the ideas of REST. In addition to being elegant, this has some important practical advantages—for example, you can use standard headers to control caching of the query results in clients and in intermediaries. Update queries should go in the body, but retrieval queries should go in the URL. (Some old proxies refused to cache URLs with query strings, but I believe that is no longer true.) Once you put aside whether to put the query in the URL or in the body, you are really just arguing "my query language is more beautiful than your query language". Contrary to what the blog post says, having a query language does not make testing easier (actually it makes it harder) and does not make clients less exposed to version change. I would summarize it this way:

  • Adding query to an API can be a good thing, although it will add significantly to implementation and testing effort.
  • Making your queries fit the REST model—i.e. putting the queries in URLs—is much better, in part because it allows you to leverage the HTTP standards for caching

In other words, queries are not an alternative to REST, rather REST provides the best model for including queries in your APIs.

Exact! I just don't understand why people oppose GraphQL to REST. People have been doing what GraphQL "formalized" for years using REST and query parameters.

I guess it's because Facebook authored it!