![]() If I have to stick with REST, I end up inventing a bespoke RPC protocol to allow for sending errors as part of the stream, either as part of the message or as a trailer header (and trailers have their own issues like no browser support). I keep running into this, and it's such a pain. Re: streams, I've found that an opaque binary stream in REST is okay, but the moment I want to stream messages, my life is hell. The received file can be treated as a stream, using very little memory. > Handling large data sizes with REST APIs, such as file uploads, is rather straight forward. Where did it say that? I got the opposite impression: > There are quite a few factual errors in this post, like no streaming in REST (not necessarily true). These will often lead to just one or two of the options here, then you can drill down into the details like tooling, API design, and so on. When deciding on an API technology the first questions must be "who is the consumer", and "what are their constraints". There are quite a few factual errors in this post, like REST not being schema based (that's up to the implementer), no streaming in REST (not necessarily true). gRPC does however offer considerably more control over streaming behaviour, more standardised error handling than GraphQL, and more. But that might be ok! Server to server calls rarely need a big cache to work around poor networking. GRPC doesn't really allow for any of this, if you want it you've got to invent it all yourself. Again, this may or may not be something you want in an API. Given GraphQL's well defined schema it's relatively easy to build generic caching mechanisms. GraphQL, like REST, is about the objects and relationships, and lends itself well to building highly capable client-side caching layers when you introduce the Relay patterns to it – particularly globally unique IDs. That may or may not be something you want in an API, but it's worth considering, because it's not going to happen with gRPC. Now web standards didn't quite manage to standardise HATEOAS, so sadly full machine discovery is unlikely via an API, but you can build quite adaptable clients that can respond to changing APIs well, going as far as optimising client usage by changing API responses without redeploying clients. The whole point of REST is that it's discoverable. I think it's a more useful engineering decision to first filter based on how you want an API to be used, and then to filter based on the implementation details such as these. While this is a nice overview (I wouldn't call it detailed), I feel it misses the points of REST, gRPC, and GraphQL.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |