1

I'm just playing a little with graphql and can not yet recognize the difference between graphql and REST with embedding and partial response.

Partial Response is used by TeamCity since years and it works as "Restful" Service

https://github.com/dotarj/PartialResponse

http://v2.wp-api.org/reference/links.html

Christian Alt-Wibbing
  • 343
  • 2
  • 8

1 Answers1

2

REST is an architectural style, not a format or a query language (like GraphQL is). It is possible to build an API which supports partial resources or a hierarchy of resources (other examples would include JSON patch or JSON Graph), but such approaches are not a conceptual part of REST. On the other hand, they are a conceptual part of GraphQL. You picked examples which bear some similarity with GraphQL, but this is not due to the fact that they are RESTful services.

On the other hand, REST is based on a few approaches that do not conform with GraphQL (or vice versa). An incomplete list includes:

  • HTTP is a building block of REST. The GraphQL specs speaks of “client” and “server”, but I didn’t read that it requires HTTP.
  • REST is based on HTTP verbs. As it seems like GraphQL doesn’t require HTTP, it can’t require HTTP verbs. This wouldn’t work, anyway, as GraphQL allows you to mix operations in one query: you can execute a mutation plus a query in one request – which would not be REST-compatible, as the query would have to be a GET, while the mutation would have to be a POST or PUT.
  • The semantics of HTTP status code are missing from GraphQL.
BlueM
  • 3,658
  • 21
  • 34
  • You are absolutely right. Maybe you can or should not compare the two things. So far, I have only seen GraphQL in connection with HTTP, as it has been inserted by Facebook for this purpose as well? – Christian Alt-Wibbing Oct 29 '16 at 16:09
  • 1
    I haven’t seen anything else than HTTP, either. In fact, I was pretty surprised that the specs leave room (specs: “sent over a transport like HTTP”) for such important things as transport or the response serialization format (JSON is “recommended”, not mandatory). Maybe makes sense when you want to assure that GraphQL can become a ubiquitous language. But I find it astonishing that many people seem to think RESTful services are “proprietary“ and that GraphQL is “open”, altough this gap in the specs allows proprietary transports or serialization formats, which would be anything – but not open. – BlueM Oct 29 '16 at 16:47