[DSteinmann]

In the first article you raised two issues about REST: Developers disagree on what it means to be "REST-ful", and HATEOS never took off, despite being the feature that distinguishes REST from other APIs.

In the second article you explained that HTML could implement HATEOS.

In the third article you argue that GraphQL is the natural progression of REST but its security model is complex to the point of being unsafe.

---

The first article, in my opinion, consisted of straw men arguments.

The second is understandable.

The third made no sense to me. With a system like GraphQL you can use a declarative column-based security model. This is, in my opinion, easier than the imperative stuff you're probably using to make your HTML endpoints secure. With GraphQL you need to set up your security constraints once. With HTML endpoints you need to remember to toggle off certain blocks of HTML for every single request. Is that what you're doing?

[carsongross]

What were the strawmen in the first article? It is observable that REST/HATEOAS (HATEOAS in particular) are falling out of favor in JSON-based APIs. This is understandable because JSON is not a hypertext, and the rest of REST isn't amazingly useful without it. Where's the strawman?

I'm glad the second article makes sense.

The core point of the third article is that when you increase the expressive power of a JSON API (with something like GraphQL) you are putting this power in the hand of the end user, not just your developers. This is not the same as giving, for example, full SQL access to your server-side only developer, where the code is executing in a trusted computing environment.

[gingerlime]

> With GraphQL you need to set up your security constraints once

I'm only superficially familiar with GraphQL, (and not at all familiar with Intercooler), but I always felt that security was glossed-over and not a core part of what it offers.[0]

Authorization is challenging enough on the server, but having a query-language power client-side, feels like a pretty fragile thing to me to secure properly. Definitely not something you just set once and forget about...

[0] http://graphql.org/learn/authorization/ - if I get it right, it gives a good example of row-based authorization and essentially tells you to figure it out for yourself in your business logic layer.