Hacker News Reader

Comment by mattmanser | Hacker News Reader

You (and we) have no clue how bad your code is.

You're suffering under Dunning-Kruger.

For example, what you described about making 4 requests with your 'REST' API, you didn't have to do that. YOU made that terrible API. That's not a feature of REST, but you seem to have mixed the two up in your head.

View on HN

The idea of a REST endpoint is to represent a resource, not a view. How will you bring good RESTful API design together with the requirement of wanting an API that serves one very specific view that depends on multiple REST APIs. This seems to be in conflict doesn't it? What's your idea on resolving this conflict without abandoning the principles of RESTful API design?

> The idea of a REST endpoint is to represent a resource, not a view

Resource is not what you think it is. The conflict you’re talking about doesn’t exist.

What feature of REST would allow you to separate your entities as they should be while being able to arbitrarily query them together?

Feature where you can write an endpoint to return whatever it is that you need. Granted, it’s not automatic as in some GraphQL frameworks - not sure if that’s what you meant by “arbitrary”. But then again, such things are a step beyond just using GraphQL as a protocol.

The comparison would be;

REST: Any time there is a new "view"; you need to go to your server and write a new endpoint.

GraphQL: You can stitch data together however you want; as long as that data is defined.

So for example if I need name of someone and the url of their children; querying it alone is enough with GraphQL whereas with REST either I need to fetch multiple times or write a new endpoint that serves both together.

Reply on news.ycombinator.com