3 ms·

> How about one HTTP request often being faster than multiple requests? Http/2 push. But also: would it actually be more dev hours to write out the custom RES

> How about one HTTP request often being faster than multiple requests? Http/2 push. But also: would it actually be more dev hours to write out the custom RESTful queries? If you're whitelisting individual queries. What's the difference then? You've just got a more awkward, uncachable, less split-routable protocol for exactly the same data. > Shouldn't you use push when you know the client will ask for the resources? Yes. If I know they intend to join data in, I can push it. I can even do this somewhat speculatively based on statistical patterns in clients. I can tune those values based on real data which can be refined over time.

exogen 9y ago
> Yes. If I know they intend to join data in, I can push it. Right, so if you don't have the full "query", which you don't with multiple REST round-trips, then you won't push it... > I can even do this somewhat speculatively based on statistical patterns in clients. I can tune those values based on real data which can be refined over time. Cool, so guessing. That's exactly what I want my API's performance profile to be based on. Sounds like a lot of work man, why don't you just use GraphQL instead? ;)
- KirinDave 9y ago
  > Right, so if you don't have the full "query", which you don't with multiple REST round-trips, then you won't push it... well. Yes. But of course, GraphQL ad hoc extensions are discussing limiting this arbitrarily as well. > Cool, so guessing. That's exactly what I want my API's performance profile to be based on. No. For example, if I can say that a banking customer wants to see a second page of transactions 90% of the time, then I should push the next page every time. If I can say they want to see the third page of transactions 10% of the time, then it makes sense to defer the cost.
andrewingram 9y ago
Once your build pipeline is setup, there's no development overhead to whitelisting queries.
- KirinDave 9y ago
  I don't actually even see the real engineering challenge of whitisting queries, outside of documentation and communicating errors. It just because a confusing and unhelpful protocol choice if you start whitelisting queries. Without the "query" part it's just a DSL for graph retreival. Why not put that client side if it is so expressive.

exogen 9y ago

> Yes. If I know they intend to join data in, I can push it. Right, so if you don't have the full "query", which you don't with multiple REST round-trips, then you won't push it... > I can even do this somewhat speculatively based on statistical patterns in clients. I can tune those values based on real data which can be refined over time. Cool, so guessing. That's exactly what I want my API's performance profile to be based on. Sounds like a lot of work man, why don't you just use GraphQL instead? ;)

KirinDave 9y ago
> Right, so if you don't have the full "query", which you don't with multiple REST round-trips, then you won't push it... well. Yes. But of course, GraphQL ad hoc extensions are discussing limiting this arbitrarily as well. > Cool, so guessing. That's exactly what I want my API's performance profile to be based on. No. For example, if I can say that a banking customer wants to see a second page of transactions 90% of the time, then I should push the next page every time. If I can say they want to see the third page of transactions 10% of the time, then it makes sense to defer the cost.

andrewingram 9y ago

Once your build pipeline is setup, there's no development overhead to whitelisting queries.

KirinDave 9y ago
I don't actually even see the real engineering challenge of whitisting queries, outside of documentation and communicating errors. It just because a confusing and unhelpful protocol choice if you start whitelisting queries. Without the "query" part it's just a DSL for graph retreival. Why not put that client side if it is so expressive.