Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)

cloud.google.com

Post reply on HN
Print view View original

201–210 of 286 posts

Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)

#201

Post by galangalalgol »

doctorpangloss wrote: post #126
azemetre wrote: post #110

Earlier quoted context omitted.

What would you recommend doing instead?

Do you need bidirectional streams? If so, you should write a bespoke protocol, on top of UDP, TCP or websockets. If you don't, use GraphQL.

What about songle directional streams? Graphql streams aren't widely supported yet are they? Graphql also strikes me as a weird alternative to protobufs as the latter works so hard for performance with binary payloads, and graphql is typically human readable bloaty text. And they aren't really queries, you can just choose to ignore parts of the return for a rpc.

Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)

#202

Post by crabbone »

stickfigure wrote: post #113
jdwyah wrote: post #76

If I could go back in time I would stop myself from ever learning about gRPC. I was so into the dream, but years later way too many headaches. Don’t do it to yourself. Saying gRPC hides the internals is a joke. You’ll get internals all right, when you’re blasting debug logging trying to figure out what the f is going on causing 1/10 requests to fail and fine tuning 10-20 different poorly named and timeout / retry set…

IMO the problem with gRPC isn't the protocol or the protobufs, but the terrible tooling - at least on the Java end. It generates shit code with awful developer ergonomics. When you run the protobuf builder... * The client stub is a concrete final class. It can't be mocked in tests. * When implementing a server, you have to extend a concrete class (not an interface). * The server method has an async method signature.…

Protobuf is an atrocious protocol. Whatever other problems gRPC has may be worse, but Protobuf doesn't make anything better that's for sure.

The reason to use it may be that you are required to by the side you cannot control, or this is the only thing you know. Otherwise it's a disaster. It's really upsetting that a lot of things used in this domain are the first attempt by the author to make something of sorts. So many easily preventable disasters exist in this protocol for no reason.

Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)

#203

Post by Octoth0rpe »

eadmund wrote: post #68
Octoth0rpe wrote: post #16

Oof, I strongly disagree with this article's description of how REST apis are used, and the distinction between openAPI and rest. If I design a REST api in 2023, and in 2024 produce an openapi yaml or json file for that API with no other changes, is it somehow no longer a REST api? of course not. The article seems to be predicated on this distinction. > The least-commonly used API model is REST Is that true? I don't…

> > A signature characteristic of [REST APIs] is that clients do not construct URLs from other information > I don't think this is true in practice. 'recursivedoubts: https://news.ycombinator.com/item?id=42799917 The blogger is completely correct. In a true REST (i.e., not JSON-RPC) API, the client has a single entry URL, then calls the appropriate HTTP verb on it, then parses the response, and proceeds to follow URL…

I think there's the REST that Fielding intended, and there's the REST that everyone has spent almost 20 years implementing. At some point we should acknowledge that the reality of REST-like API design is a valid thing to point to and say "that's REST!" even if it doesn't implement all of Fielding's intentions.

To me the critical part of REST is the use of http semantics in API design, which makes it very un-RPC like.

The idea of a naive api client crawling through an API to get at the data that it needs seems so disconnected from the reality of how _every api client I've ever implemented_ works in a practical sense that it's unfathomable to me that someone thinks that this is a good idea. I mean, as a client, I _know_ that I want to fetch a specific `order` object, and I read the documentation from the API provider (which may in fact be me as well, at least me as an organization). I know the URL to load an order is GET /orders/:id, and I know the url to logout is DELETE /loginSession. It would never make sense to me to crawl an API that I understand from the docs to figure out if somehow the url for fetching orders has changed.

I do think we need some kind of description of REST 2.0 that makes sense in today's world. It certainly does not involve clients crawling through entry urls and relationships to discover paths that are clearly documented. It probably does involve concepts of resources and collections of resources, it certainly mandates specific uses for each http method. It should be based on the de facto uses of REST in the wild. And this thing would _definitely_ not look like an rpc-oriented api (eg soap, grpc).

Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)

#204

Post by crabbone »

This post is exactly how I imagine people who only ever worked at Google to think. This has been my experience from having to work at Google and to work with Google.

Bizarre definitions of commonly used words. Huge emphasis on in-house tech, which is mediocre at best. Extraordinary claims supported by fictional numbers.

I think, there used to be a culture where employees scored some brownie points by publishing blogs. You'd need those points to climb the ranks or to just even keep your job. This blog reads as one of those: nothing of substance, bunch of extraordinary claims and some minutia about Google's internal stuff that's of little consequence to anyone outside the company.

I mean... choosing gRPC of all things to illustrate RPC, when there's actual Sun's RPC in every Linux computer is just the cherry on top.

Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)

#205

Post by afiodorov »

I’ve generally regarded gRPC as a high-performance protocol mainly suited for connecting microservices—something you’d keep internal rather than expose publicly. But it shines in use cases like live captioning, where a transcription service has to stay in sync with a video feed and can’t afford dropped messages. In my experience, using plain WebSockets for high-throughput internal communication was a mistake because while WebSockets use TCP underneath, they don’t inherently handle reconnection or message acknowledgments. With gRPC, those features come built-in, saving you from implementing them yourself.

Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)

#206

Post by crabbone »

bitzun wrote: post #30

Unless you are doing bidirectional streaming (for which it seems pretty well suited, but I haven't used it, so it might be a fucking mess), grpc is usually a waste of time. Runtime transitive dependency hell, toolchain hell, and the teams inside Google that manage various implementations philosophically disagree on how basic features should work. Try exposing a grpc api to a team that doesn't use your language (parti…

Nothing in Protobuf is suited for streaming. It's anti-streaming compared to almost any binary protocol you can imagine (unless you want to stream VHD, which would be a sad joke... for another time).

Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)

#207

Post by crabmusket »

jahewson wrote: post #79
recursivedoubts wrote: post #28

> If your API is a REST API, then your clients never have to understand the format of your URLs and those formats are not part of the API specification given to clients. Roy Fielding, who coined the term REST: "A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any…

This idea of self-describing REST is now better known as HATEOAS. Personally I think it’s bloated and doesn’t solve a real problem. https://en.m.wikipedia.org/wiki/HATEOAS

HATEOAS is fantastic when your clients are humans. Not so much when they're code.

Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)

#208

Post by cpursley »

oppositelock wrote: post #98

I've been building API's for a long time, using gRPC, and HTTP/REST (we'll not go into CORBA or DCOM, because I'll cry). To that end, I've open sourced a Go library for generating your clients and servers from OpenAPI specs ( https://github.com/oapi-codegen/oapi-codegen ). I disagree with the way this article breaks down the options. There is no difference between OpenAPI and REST, it's a strange distinction. OpenAPI…

I'm piggybacking on the OpenAPI spec as well to generate a SQL-like query syntax along with generated types which makes working with any 3rd party API feel the same.

What if you could query any ole' API like this?:

  Apipe.new(GitHun) |> from("search/repositories") |> eq(:language, "elixir") |> order_by(:updated) |> limit(1) |> execute()
This way, you don't have to know about all the available gRPC functions or the 3rd party API's RESTful quirks while retaining built-in documenting and having access to types.

https://github.com/cpursley/apipe

I'm considering building a TS adapter layer so that you can just drop this into your JS/TS project like you would with Supabase:

  const { data, error } = await apipe.from('search/repositories').eq('language', 'elixir').order_by('updated').limit(1)
Where this would run through the Elixir proxy which would do the heavy lifting like async, handle rate limits, etc.

Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)

#209

Post by recursivedoubts »

deathanatos wrote: post #112
recursivedoubts wrote: post #28

> If your API is a REST API, then your clients never have to understand the format of your URLs and those formats are not part of the API specification given to clients. Roy Fielding, who coined the term REST: "A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any…

> the "API specification" given to clients, in a truly RESTful system, should only be the initial entry point URI/URL I don't know that I fully agree? The configuration , perhaps, but I think the API specification will be far more than just a URL. It'll need to detail whatever media types the system the API is for uses. (I.e., you'll need to spend a lot of words on the HTTP request/response bodies, essentially.) From…

that should not be API specific, otherwise you are just smuggling an API specification into a second-order aspect of your system and violating the uniform interface.

Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)

#210

Post by recursivedoubts »

curt15 wrote: post #49
recursivedoubts wrote: post #28

> If your API is a REST API, then your clients never have to understand the format of your URLs and those formats are not part of the API specification given to clients. Roy Fielding, who coined the term REST: "A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any…

How does one even write an API client against a REST API that only publishes the initial entry point? in particular, how should the client discover the resources that can be manipulated by the API or the request/response models?

your browser is a client that works against RESTful entries points that only publish an initial entry point, such as https://news.ycombinator.com

from that point forward the client discovers resources (articles, etc) that can be manipulated (e.g. comments posted and updated) via hypermedia responses from the server in responses

Post reply on HN