[carsongross]

That's a great response Andy.

I'd also say that JSON APIs either tend to get tuned for specific UX needs or become more and more expressive. The first option calls into question the general, reusable nature of the API, and the second introduces security issues in an untrusted computing environment[1].

I typically split out the JSON API for my system from the web application proper so that my web application needs don't screw up the public API of the system. They end up being two separate concerns with different shapes, authentication methods, etc.

[1] - http://intercoolerjs.org/2016/02/17/api-churn-vs-security.ht...

[joesb]

This is where things like GraphQL come in.

[ryanbrunner]

Customers aren't going to use GraphQL for a public API, so you've just added another (micro) service to talk to the GraphQL server and translate it into a more traditional REST API (or the other way around if you want your internals to be REST). Also, you've pretty much forced an entire ecosystem of complexity onto your front end.

And then you've added a ton of complexity, bringing us full circle.

Based on the parent comments, we're talking about simple websites where serving HTML through AJAX is an effective approach. In the name of "purity", you've introduced JSON APIs, GraphQL, (most likely) React and Relay, more complex deployment with multiple services, probably a complex front-end buildchain, and who knows what else.

[lmm]

> Customers aren't going to use GraphQL for a public API

Why not?

[ryanbrunner]

Right now this isn't feasible. People are used to REST APIs, and the tooling and documentation (particularly outside of use with React and Relay) for GraphQL isn't where it needs to be for it to be feasible for a customer-facing API.