Projects where REST is more suitable over GraphQL?

问题:

Based on the articles I read, GraphQL is more resource-efficient in terms of roundtrips and it can also do what REST can provide. What are the reasons why software architect & developers might decide to stay with REST over GraphQL given that the web application will just be started from scratch? Also given that this is a continuous project, will be consumed from web and mobile and openID connect is a requirement.

回答1:

In my opinion, it is – among other aspects – also a question of use cases:

• If you have something like an app or other frontend with a connection that is slow and/or has high latency (typical example: a mobile app), GraphQL’s “roundtrip minimisation” can be a big plus. And it can be pretty handy to give the client-side control over the data structure, thus often reducing the number of required API endpoints.
• If it’s rather data exchange between servers, the fact that RESTful APIs are strongly related to HTTP, has advantages such as the semantics of verbs (which GraphQL cannot offer, as you perform several operations with one GraphQL query) and status codes. Plus: you get all the HTTP caching functionality for free, which can be really important in heavily data-driven applications/services. In addition, REST is ubiquitous (although probably most APIs advertised as “RESTful” aren’t, often due to missing support for hypermedia).

回答2:

This is a rather broad question but I'll try answer speaking from my own experience.

REST provides access to a specific resource, e.g. a user or a product. The result from a request will likely be an assumption of what data you will want or use, i.e. it's probably everything about that resource regardless of whether you use all the data or not.

There is also the problem of N+1. As an example, take the user has and belongs to many relationships scenario; with a RESTful API you would make a request to the user, e.g. /users/:id then make a request to all their relationships, e.g. /users/:id/relationships, so that's two requests already. There could be an assumption of the relationships endpoint to include both the relationship (friend, family member, etc.) and the user in the resulting array, but if the API doesn't make that assumption, you're going to have to make a request to each user endpoint to get the data on each user in each relationship.

This example can go deeper too; what if you want all second tier relationships (friends of friends for instance)?

GraphQL solves this by allowing you to ask for specifically what you need. You can construct a query to return the data at depth:

query myQuery($userId: ID!) {
  user(id: $userID) {
    id
    name
    relationships {
      id
      type
      user {
        id
        name
        relationships {
          id
          type
          user {
            id
            name
          }
        }
      }
    }
  }
}

Fragments could clean this up a bit and there may be recursive issues, but you should get the idea; one request gets you all the nested data you need.

If you don't have much need for such nested or inter-connected result sets, GraphQL may not offer much in a trade between benefit and complexity.

However, one of the greatest benefits I have found with GraphQL is its extensibility and self-documentation.

回答3:

There might be multiple reasons. This is very subjective I believe, but to me it's based on:

REST is the old and steady way. It is used by the most and provides an easy interface to API consumers. Because it's old (by no means a bad thing) most developers know of it and know how to consume it.

GraphQL is the new guy in town. It sure does save some performance (roundtrips and payload) for most systems, but does change the way we think of a backend. Instead of providing resource endpoints, it provides the graph of the data model and let the consumer decide what data to get.

As of the point of the "new guy", GraphQL is not as battle tested. It is new to most and there fore not adopted by others and the first-movers and startups, basically.

But again, this is a subjective question with a subjective answer. Currently I am using GraphQL for a startup to test it's durability and see if it can solve our needs. So far, it does by far. If you are to make a decision on wether to start a new project with REST or GraphQL you should be consider your needs and how much money/time you want to spend learning new vs. doing what you know and get to your goal faster.