6 ms·

Things I "love" about REST APIs: - How should I pass an argument? Let me count the many ways: 1. Path parameters 2. Query parameters in the URL 3.

Things I "love" about REST APIs: - How should I pass an argument? Let me count the many ways: 1. Path parameters 2. Query parameters in the URL 3. Query parameters in the body of the request 4. JSON/YAML/etc. in the body of the request 5. Request headers (yes, people use these for API tokens, API versions, and other things sometimes) - There's also the REST verb that is often super arbitrary. PUT vs POST vs PATCH... so many ways to do the same thing. - HTTP response codes... so many numbers, so little meaning! There are so many ways to interpret a lot of these codes, and people often use 200 where they really "should" use 202... etc. Response codes other than 200 and 500 are effectively never good enough by themselves, so then we come to the next part: - HTTP responses. Do we put the response in the body using JSON, MessagePack, YAML, or which format do we standardize on? Response headers are used for... some things? Occasionally, responses like HTTP redirects will often just throw HTML into API responses where you're normally using JSON. - Bonus round: HTTP servers will often support compressing the response, but almost never do they allow compressing the request body, so if you're sending large requests frequently... well, oops. I don't personally have experience with gRPC, but REST APIs can be a convoluted mess, and even standardizing internally only goes so far. I like the promise of gRPC, where it handles all of the mundane transport details for me, and as a bonus... it will generate client implementations from a definition file, and stub out the server implementation for me... in whatever languages I want. Why wouldn't you want that?

kbar13 6y ago
Also writing bespoke REST clients for every single endpoint is just a huge waste of time and error prone since there’s so many ways of doing everything. One of my biggest gripes with REST APIs is having identifiers in url path instead of in query params or the request body
- spockz 6y ago
  Honestly, swagger and OpenApi have existed for ages. Who still creates bespoke rest clients? It took me one day to create a template for generating code that links our http client of choice to api specifications. These also exist out of the box for many clients like ribbon.
Guthur 6y ago
Because all those questions are the easy ones. gRPC is not a magic bullet for the problems of state management. It'll have all the same issues RPC has had for the last 30 years in that it enforces no discipline where it counts, state management. The real problem with REST is that state management across a distributed system is hard, real hard. So hard actually that we decide to ignore that it's a problem at all and instead get obsessed with client side interface code, transport protocol, or content types etc, the easy mechanical stuff. gRPC wont be a magic bullet, just like CORBA wasn't, or XML-RPC, or SOAP. History does like to repeat itself...
- coder543 6y ago
  I'm not saying they're hard questions. They're annoying, pointless questions that I have to answer every single time I create or consume a REST API. Those pointless questions also create very real bugs that I have dealt with for years, because humans make mistakes. It's a complete waste of time and energy for everyone involved. Every one of these questions creates additional mental overhead and an opportunity for incorrect implementation. I would rather deal with meaningful decisions as often as possible, like questions of state management, instead of constantly deciding what color to paint the bike shed based on each person's interpretation of what "the most RESTy" API should look like. You didn't seem to disagree with me in any way... I see nowhere in your comment where you say that REST APIs are better than gRPC, or why you would pick to make a REST API over gRPC or vice versa. Your rant just has nothing to do with my comment, as far as I can tell? I never claimed that `gRPC` would solve state management. I never even mentioned state management. So... cool? gRPC is not a magic bullet, I completely agree. It's a tool, and it seems to have advantages over REST APIs. That's what we're discussing here, since the OP asked why someone would use gRPC. Your comment seems to imply that it's pointless to improve one problematic situation (RPC) without completely fixing all other problems in existence.
  - Guthur 6y ago
    If you're working in a group think conformist organisation with a single mono repo like Goolge then gRPC certainly has some allure. But if I'd like to remain a little more decoupled it's not very good at all. REST is definitely not a magic bullet either because more often than not we fail to do that hard modelling aspect well enough.
awinder 6y ago
"HTTP servers will often support compressing the response, but almost never do they allow compressing the request body" What doesn't have great support for Content-Encoding headers?
- coder543 6y ago
  What does have great support? Content-Encoding works great from server -> client, but not the other way around, in my experience. That's the problem I'm discussing. It's theoretically possible to support. See this stackoverflow question for one brief discussion: https://stackoverflow.com/q/20507007 https://stackoverflow.com/q/20507007 I've looked around for this feature and rarely found it to be supported... but it's also rarely discussed.
  - stephenr 6y ago
    the first answer to that question links to the Apache docs, it’s a one line change to add support, possibly with an additional block around it to limit scope to certain urls. If built in support that works with one config statement isn’t “great” support, what is?
    - coder543 6y ago
      It’s not great if you want to use someone else’s API that way to save on egress bandwidth costs... that’s what. They don’t usually let me edit their Apache configs. Apache being the only thing to support it also wouldn’t count as great. They specifically mentioned uncertainty around nginx. Have you tested any of your APIs to see if they support it?
      - stephenr 6y ago
        It's going to have possible benefits for a small niche of application types. If the 3rd party services you use, accept large amounts of normally uncompressed data that is a viable candidate for transport compression, and they don't support it: that's on them. The technology is there to do it. As for if I've "tested it". No. Because as I said: this is going to benefit only a small niche of application types. The vast majority of applications built by the vast majority of developers are going to unlikely to see any benefit at all from this type of compression, because it's not a common pattern. Add to that, most applications are likely running in an environment where spending precious CPU cycles to compress data to send over a pipe that they're unlikely to saturate anyway, is not a winning proposition.
jayd16 6y ago
>- There's also the REST verb that is often super arbitrary. PUT vs POST vs PATCH... so many ways to do the same thing. These have clearly defined caching and indempotency differences. They are not the same. I don't believe gRPC handles this or it looks like its experimental.
- coder543 6y ago
  > These have clearly defined caching and indempotency differences. They are not the same. Clearly defined...? Maybe? I don't know of any popular HTTP proxies that rely on these definitions to automatically decide how to cache things, because people in the real world follow the definitions very loosely. GET is the only one that I've seen relied on, and it's still just a good bet, not a guarantee. Usually, you have to define which routes are cacheable and carefully configure the cache settings... in my experience, at least. Maybe it's just my bad luck to have encountered all the ways these verbs aren't used consistently over the years. They're a hint towards what will happen... at best. In my experience, anything goes, no matter what the verb says. I truly hope you've had a better experience, and that it's just me. > I don't believe gRPC handles this or it looks like its experimental. Which seems fine. We can't rely on HTTP verbs for state management because of how inconsistent implementations are, so I don't expect gRPC to do that either, but at least gRPC won't make you choose a random verb.
  - stephenr 6y ago
    I don’t know of any proxy in the wild that will cache anything other than GET or HEAD requests by default.
  - jayd16 6y ago
    >GET is the only one that I've seen relied on You're so quick to throw away a vastly used caching mechanism as if it's nothing.
    - coder543 6y ago
      GET was never the verb under discussion. I specifically listed PATCH, PUT, and POST as being effectively meaningless in practice. You can’t rely on APIs to do what the verbs say they will do. I only called out GET to say that it is still only a good bet that it will do what it is supposed to do. It’s absolutely not guaranteed. You’ve never encountered GET web routes that mutate backend state? People rely on it —- but that doesn’t make it reliable. “Throwing away” verbs like GET is not the same as throwing out caching. Please don’t twist my words into what they were not. In practice, you often still need to specify exactly which routes to cache, and how to cache them. Just using GET doesn’t magically make things cached, and you can just as easily cache non-GET routes once you’re specifying what to cache. Caching can be done for anything. It isn’t some special feature of HTTP or REST APIs.
dragonwriter 6y ago
> 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.
- sharx 6y ago
  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.
- rhacker 6y ago
  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".
  - dragonwriter 6y ago
    > 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.
rswail 6y ago
Because RPC is brittle. It requires both server and client to agree on the definition. It requires a shared IDL. If used as more than just the protobuf serialization format, it hides the remote part of RPC and programmers forget about network failures. It requires a different naming service from the standard internet naming service (DNS) which is brittle across network boundaries. If you want to avoid bikeshedding for REST APIs, adopt a standard like JSON API [1]. Adopt a specification standard like OpenAPI [2] and JSON Schema [3]. There is tooling to give you the client/server stubs like gRPC. Implement using HTTP/2 with fallback to HTTP and you get compression and multiple channels per connection. gRPC is a repeat of CORBA is a repeat of ONC-RPC is a repeat of... there's common reasons why RPC as a concept is brittle and tightly couples implementations of clients and servers. [1] https://jsonapi.org/ https://jsonapi.org/ [2] https://swagger.io/specification/ https://swagger.io/specification/ [3] https://json-schema.org/ https://json-schema.org/
- coder543 6y ago
  > If used as more than just the protobuf serialization format, it hides the remote part of RPC and programmers forget about network failures. This is like saying all programs should be written in C, because otherwise programmers forget about how memory allocation works and the cost involved. Any good REST client implementation abstracts away the remoteness too, apart from occasionally returning a network error the caller. I’m definitely not sitting there twiddling bits to call a REST API. > It requires both server and client to agree on the definition. This is true of literally every API. If the client and the server disagree on a REST API call, nothing good is going to happen. Period. gRPC is designed to allow evolution of APIs where clients and servers have different versions of the IDL. It’s no more brittle than a JSON API, and arguably it’s actually less brittle because of how the approach it takes. > It requires a different naming service from the standard internet naming service (DNS) which is brittle across network boundaries. That is unequivocally false. It doesn’t use a special naming service to connect servers and clients, unless you specifically choose to override the default behavior, which you could also do with JSON API if you wanted to make it really brittle as well. Instead just use DNS, which is the default for both. It absolutely doesn’t require a special naming service, as you claim. gRPC is built on the HTTP/2 standard. Based on the rest of your comment, you clearly also didn’t know this. > gRPC is a repeat of CORBA is a repeat of ONC-RPC is a repeat of... there's common reasons why RPC as a concept is brittle and tightly couples implementations of clients and servers. Your information so far can be trivially disproven, so... apologies if I’m not going to take advice from you on this subject right now. I’m glad JSON API works for you. EDIT: I see you repeated a lot of this misinformation in yet another comment. I get it —- the very idea of RPC is offensive to you. But you should at least research the technology you’re ranting about. Your information about gRPC is entirely, factually wrong.
BerislavLopac 6y ago
I wanted to implements gRPC several times but every time ran away due to the terrible state of Python support. It would need a complete rewrite to be remotely usable.

kbar13 6y ago

Also writing bespoke REST clients for every single endpoint is just a huge waste of time and error prone since there’s so many ways of doing everything. One of my biggest gripes with REST APIs is having identifiers in url path instead of in query params or the request body

spockz 6y ago
Honestly, swagger and OpenApi have existed for ages. Who still creates bespoke rest clients? It took me one day to create a template for generating code that links our http client of choice to api specifications. These also exist out of the box for many clients like ribbon.

Guthur 6y ago

Because all those questions are the easy ones. gRPC is not a magic bullet for the problems of state management. It'll have all the same issues RPC has had for the last 30 years in that it enforces no discipline where it counts, state management. The real problem with REST is that state management across a distributed system is hard, real hard. So hard actually that we decide to ignore that it's a problem at all and instead get obsessed with client side interface code, transport protocol, or content types etc, the easy mechanical stuff. gRPC wont be a magic bullet, just like CORBA wasn't, or XML-RPC, or SOAP. History does like to repeat itself...

coder543 6y ago
I'm not saying they're hard questions. They're annoying, pointless questions that I have to answer every single time I create or consume a REST API. Those pointless questions also create very real bugs that I have dealt with for years, because humans make mistakes. It's a complete waste of time and energy for everyone involved. Every one of these questions creates additional mental overhead and an opportunity for incorrect implementation. I would rather deal with meaningful decisions as often as possible, like questions of state management, instead of constantly deciding what color to paint the bike shed based on each person's interpretation of what "the most RESTy" API should look like. You didn't seem to disagree with me in any way... I see nowhere in your comment where you say that REST APIs are better than gRPC, or why you would pick to make a REST API over gRPC or vice versa. Your rant just has nothing to do with my comment, as far as I can tell? I never claimed that `gRPC` would solve state management. I never even mentioned state management. So... cool? gRPC is not a magic bullet, I completely agree. It's a tool, and it seems to have advantages over REST APIs. That's what we're discussing here, since the OP asked why someone would use gRPC. Your comment seems to imply that it's pointless to improve one problematic situation (RPC) without completely fixing all other problems in existence.
- Guthur 6y ago
  If you're working in a group think conformist organisation with a single mono repo like Goolge then gRPC certainly has some allure. But if I'd like to remain a little more decoupled it's not very good at all. REST is definitely not a magic bullet either because more often than not we fail to do that hard modelling aspect well enough.

awinder 6y ago

"HTTP servers will often support compressing the response, but almost never do they allow compressing the request body" What doesn't have great support for Content-Encoding headers?

coder543 6y ago
What does have great support? Content-Encoding works great from server -> client, but not the other way around, in my experience. That's the problem I'm discussing. It's theoretically possible to support. See this stackoverflow question for one brief discussion: https://stackoverflow.com/q/20507007 https://stackoverflow.com/q/20507007 I've looked around for this feature and rarely found it to be supported... but it's also rarely discussed.
- stephenr 6y ago
  the first answer to that question links to the Apache docs, it’s a one line change to add support, possibly with an additional block around it to limit scope to certain urls. If built in support that works with one config statement isn’t “great” support, what is?
  - coder543 6y ago
    It’s not great if you want to use someone else’s API that way to save on egress bandwidth costs... that’s what. They don’t usually let me edit their Apache configs. Apache being the only thing to support it also wouldn’t count as great. They specifically mentioned uncertainty around nginx. Have you tested any of your APIs to see if they support it?
    - stephenr 6y ago
      It's going to have possible benefits for a small niche of application types. If the 3rd party services you use, accept large amounts of normally uncompressed data that is a viable candidate for transport compression, and they don't support it: that's on them. The technology is there to do it. As for if I've "tested it". No. Because as I said: this is going to benefit only a small niche of application types. The vast majority of applications built by the vast majority of developers are going to unlikely to see any benefit at all from this type of compression, because it's not a common pattern. Add to that, most applications are likely running in an environment where spending precious CPU cycles to compress data to send over a pipe that they're unlikely to saturate anyway, is not a winning proposition.

jayd16 6y ago

>- There's also the REST verb that is often super arbitrary. PUT vs POST vs PATCH... so many ways to do the same thing. These have clearly defined caching and indempotency differences. They are not the same. I don't believe gRPC handles this or it looks like its experimental.

coder543 6y ago
> These have clearly defined caching and indempotency differences. They are not the same. Clearly defined...? Maybe? I don't know of any popular HTTP proxies that rely on these definitions to automatically decide how to cache things, because people in the real world follow the definitions very loosely. GET is the only one that I've seen relied on, and it's still just a good bet, not a guarantee. Usually, you have to define which routes are cacheable and carefully configure the cache settings... in my experience, at least. Maybe it's just my bad luck to have encountered all the ways these verbs aren't used consistently over the years. They're a hint towards what will happen... at best. In my experience, anything goes, no matter what the verb says. I truly hope you've had a better experience, and that it's just me. > I don't believe gRPC handles this or it looks like its experimental. Which seems fine. We can't rely on HTTP verbs for state management because of how inconsistent implementations are, so I don't expect gRPC to do that either, but at least gRPC won't make you choose a random verb.
- stephenr 6y ago
  I don’t know of any proxy in the wild that will cache anything other than GET or HEAD requests by default.
- jayd16 6y ago
  >GET is the only one that I've seen relied on You're so quick to throw away a vastly used caching mechanism as if it's nothing.
  - coder543 6y ago
    GET was never the verb under discussion. I specifically listed PATCH, PUT, and POST as being effectively meaningless in practice. You can’t rely on APIs to do what the verbs say they will do. I only called out GET to say that it is still only a good bet that it will do what it is supposed to do. It’s absolutely not guaranteed. You’ve never encountered GET web routes that mutate backend state? People rely on it —- but that doesn’t make it reliable. “Throwing away” verbs like GET is not the same as throwing out caching. Please don’t twist my words into what they were not. In practice, you often still need to specify exactly which routes to cache, and how to cache them. Just using GET doesn’t magically make things cached, and you can just as easily cache non-GET routes once you’re specifying what to cache. Caching can be done for anything. It isn’t some special feature of HTTP or REST APIs.

dragonwriter 6y ago

> 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.

sharx 6y ago
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.
rhacker 6y ago
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".
- dragonwriter 6y ago
  > 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.

rswail 6y ago

Because RPC is brittle. It requires both server and client to agree on the definition. It requires a shared IDL. If used as more than just the protobuf serialization format, it hides the remote part of RPC and programmers forget about network failures. It requires a different naming service from the standard internet naming service (DNS) which is brittle across network boundaries. If you want to avoid bikeshedding for REST APIs, adopt a standard like JSON API [1]. Adopt a specification standard like OpenAPI [2] and JSON Schema [3]. There is tooling to give you the client/server stubs like gRPC. Implement using HTTP/2 with fallback to HTTP and you get compression and multiple channels per connection. gRPC is a repeat of CORBA is a repeat of ONC-RPC is a repeat of... there's common reasons why RPC as a concept is brittle and tightly couples implementations of clients and servers. [1] https://jsonapi.org/ https://jsonapi.org/ [2] https://swagger.io/specification/ https://swagger.io/specification/ [3] https://json-schema.org/ https://json-schema.org/

coder543 6y ago
> If used as more than just the protobuf serialization format, it hides the remote part of RPC and programmers forget about network failures. This is like saying all programs should be written in C, because otherwise programmers forget about how memory allocation works and the cost involved. Any good REST client implementation abstracts away the remoteness too, apart from occasionally returning a network error the caller. I’m definitely not sitting there twiddling bits to call a REST API. > It requires both server and client to agree on the definition. This is true of literally every API. If the client and the server disagree on a REST API call, nothing good is going to happen. Period. gRPC is designed to allow evolution of APIs where clients and servers have different versions of the IDL. It’s no more brittle than a JSON API, and arguably it’s actually less brittle because of how the approach it takes. > It requires a different naming service from the standard internet naming service (DNS) which is brittle across network boundaries. That is unequivocally false. It doesn’t use a special naming service to connect servers and clients, unless you specifically choose to override the default behavior, which you could also do with JSON API if you wanted to make it really brittle as well. Instead just use DNS, which is the default for both. It absolutely doesn’t require a special naming service, as you claim. gRPC is built on the HTTP/2 standard. Based on the rest of your comment, you clearly also didn’t know this. > gRPC is a repeat of CORBA is a repeat of ONC-RPC is a repeat of... there's common reasons why RPC as a concept is brittle and tightly couples implementations of clients and servers. Your information so far can be trivially disproven, so... apologies if I’m not going to take advice from you on this subject right now. I’m glad JSON API works for you. EDIT: I see you repeated a lot of this misinformation in yet another comment. I get it —- the very idea of RPC is offensive to you. But you should at least research the technology you’re ranting about. Your information about gRPC is entirely, factually wrong.

BerislavLopac 6y ago

I wanted to implements gRPC several times but every time ran away due to the terrible state of Python support. It would need a complete rewrite to be remotely usable.