4 ms·
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
by mattmanser 6y ago
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.
- htkibar 6y agoWhat feature of REST would allow you to separate your entities as they should be while being able to arbitrarily query them together?
- balfirevic 6y agoFeature 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.
- htkibar 6y agoThe 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.
- jensneuse 6y agoThe 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?
- balfirevic 6y ago> 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.