> They were not in spec because the spec doesn't say anything over which medium If not the spec, then original documentation. GET is a late add-on. > How do c

> They were not in spec because the spec doesn't say anything over which medium If not the spec, then original documentation. GET is a late add-on. > How do cache headers not work well with GraphQL GET requests? In REST: - a resource is uniquely identified by it's URI - when the server sends back cache headers, any client in between (any proxies, the browser, any http clients in any programming language etc.) can and will use these cache headers to cache the request In GraphQL GET: - http://myapi/graphql?query={user{id,name} http://myapi/graphql?query={user{id,name}} and http://myapi/graphql?query={user{name,id} http://myapi/graphql?query={user{name,id}} are two different requests - it gets worse for more complex queries, especially if they are dynamically constructed on the client - each of those is viewed as a separate query with separate caching - cache normalisation and query normalisation are a thing in the graphql world (and non-existent in REST) because of that. That's a yet another layer of complexity that you have to deal with > And what exactly are those benefits? I'm here defending GraphQL yet none of the downsides of REST are being taken into account. I wish anyone was willing to discuss the downsides of GraphQL. Bashing REST is the norm, but GraphQL is the holy grail that accepts no criticism. Benefits of REST over GraphQL, off the top of my head: - it's HTTP, plain and simple. So everything HTTP has to offer is directly available in REST. See this HTTP decision diagram [1] - caching doesn't require you to normalise and unpack every single request and response just to figure out if something is cached - You know your requests, so you can provide optimised queries, resolution strategies, necessary calls to external services as required by the call > There are tools like Postgraphile that solve this. It converts your GraphQL query into one efficient database query. I'd love to see that proven for any sufficiently complex and large database. > And what prevents anyone from hammering a REST API? No ad-hoc queries prevents anyone from hammering a REST API that you can specifically tune to the specific request and data you need. GraphQL requires significantly more care especially if you're not running it on just one database. And even then, oops, joins: https://news.ycombinator.com/item?id=25014918 https://news.ycombinator.com/item?id=25014918 And we're back to requiring the graphql server to be able to limit recursion depth, query complexity, etc. etc. [1] https://github.com/for-GET/http-decision-diagram/tree/master/doc https://github.com/for-GET/http-decision-diagram/tree/master...