Application Load Balancers enables gRPC workloads with end to end HTTP/2 support

Re:Application Load Balancers enables gRPC workloads with en... by dragonwriter on Friday October 30, 2020 @05:56PM (#24947252)

> There's also the REST verb

HTTP verbs. REST is a protocol-neutral architectural style (of which HTTP is an implementation), it doesn't have verbs.

> that is often super arbitrary. PUT vs POST vs PATCH...

They aren't arbitrary, they have well-defined semantic differences. It's true that “REST” APIs built over HTTP often play fast and loose with HTTP semantics, but that's not a feature of REST so much as people understanding neither REST not HTTP.

> HTTP response codes... so many numbers, so little meaning!

HTTP Status Codes have very well defined meanings.

> Response codes other than 200 and 500 are effectively never good enough by themselves, so then we come to the next part

201, 202, 204, 3xx, 4xx, and 5xx are usually fine alone, though sometimes it's nice to augment 4xx/5xx with additional info.

200, on the other hand, usually needs more info unless it's being used in a case where 201/204 would be more specific.

[ Parent | on HN ]

Re:Application Load Balancers enables gRPC workloads with en... by sharx on Friday October 30, 2020 @06:56PM (#24947625)

Re: the verbs, gRPC is built on top of HTTP, and does not use the verbs (it's always POST). So I think it was fair to call them "REST verbs" in this context.

[ Parent | on HN ]

Re:Application Load Balancers enables gRPC workloads with en... by rhacker on Friday October 30, 2020 @11:50PM (#24949002)

But I thought REST was a "protocol neutral architectural style", so why are we stuck with 200, 201, 202, 204, 3xx, 4xx, 5xx which "are usually fine alone".

[ Parent | on HN ]

Re:Application Load Balancers enables gRPC workloads with en... by dragonwriter on Saturday October 31, 2020 @04:04AM (#24949825)

> But I thought REST was a "protocol neutral architectural style",

It is.

> so why are we stuck with 200, 201, 202, 204, 3xx, 4xx, 5xx which "are usually fine alone".

I reject the stuck-with description, which I did not make, but the reason we can catalog those as existing and having those features is because, in context, we're discussing REST-over-HTTP and adhering to the semantics of the underlying protocol without ad hoc extension or modification is part of the REST architectural style, with the purpose of minimizing API-specific out-of-band knowledge that must be transferred to use the API. And the definition of the semantics of those messages in HTTP undergirds the summary I provided.

[ Parent | on HN ]