3 ms·
My only concern is if the app wants the value immediately. I don't want to have to make a separate GET after receiving a VALUE url to get the info. I understand
by jprince 12y ago
My only concern is if the app wants the value immediately. I don't want to have to make a separate GET after receiving a VALUE url to get the info. I understand why this is useful if I'm passing it along, but what if I'm not?
- 1_player 12y agoYou don't have to worry as, I would suppose, redirects are resolved automatically by the browser or any sane HTTP client library.
- michaelmior 12y agoThis still results in increased latency at worst as you may now have two round trips for every GET.
- simonw 12y agoI think you could solve this using SPDY, which lets to send an expected follow-on request in the same stream of bytes before it has been requested - originally designed for things like CSS but it should apply equally well here (especially given the UUID URL caching semantics)
- notdonspaulding 12y agoWhether or not that's more efficient boils down to how much the server can predict the client's behavior though, right? I'm just thinking that if the server was configured to respond with the /value/ reference and then immediately follow that up with the resource, your client doesn't really have much say in how noisy the conversation is over the wire.
- sushidev 12y agoIt could return a 200 response with the actual value and the value id in an additional header. Not as elegant as 302 but more practical (from the efficiency point of view).
- sushidev 12y agoIt could return a 200 response with the actual value and the value id in an additional header. Not as elegant as 302 but more practical (from the efficiency point of view).