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

131–140 of 286 posts

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

#131

Post by kelseyfrog »

mplanchard wrote: post #83
eadmund wrote: post #74

Earlier quoted context omitted.

Language is a means of communication, and we have to have some sort of agreement on terms. REST had an original meaning; that is a useful thing to be able to discuss. JSON-RPC is also a useful thing to discuss. But the two things are different . It’s confusing to use the one word or phrase to mean two different things (like ‘inflammable’!). Granted, language is to some extent defined by usage: if enough people use a…

REST’s original meaning is pretty ambiguous and poorly specified. The dissertation was written to describe the design and architecture of the HTTP protocol itself, which was largely designed with and alongside this concept of REST. It predates a lot of modern Internet usage and thus doesn’t map perfectly onto current paradigms. I’d argue that even saying a “REST API” means you’re already in the land of impurity. “Tru…

It is. One of the biggest points of tension is that we've more or less settled on JSON as an interchange format which is not exactly hypermedia put of the box. That contradiction has severe implications in the application of HATEOS as it exists re JSON APIs.

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

#132

Post by matrix87 »

inetknght wrote: post #85
abalaji wrote: post #80

Everyone is hating on gRPC in this thread, but I thought I'd chime in as to where it shines. Because of the generated message definition stubs (which require additional tooling), clients almost never send malformed requests and the servers send a well understood response. This makes stable APIs so much easier to integrate with.

> Because of the generated message definition stubs (which require additional tooling), clients almost never send malformed requests and the servers send a well understood response. Sure. Until you need some fields to be optional. > This makes stable APIs so much easier to integrate with. Only on your first iteration. After a year or two of iterating you're back to JSON, checking if fields exist, and re-validating yo…

> After a year or two of iterating you're back to JSON, checking if fields exist, and re-validating your data.

Every time this has happened to me, it's because of one-sided contract negotiation and dealing with teams where their incentives are not aligned

i.e. they can send whatever shit they want, and we have to interpret it and make it work

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

#133

Post by deathanatos »

physicles wrote: post #118
eadmund wrote: post #74

Earlier quoted context omitted.

Language is a means of communication, and we have to have some sort of agreement on terms. REST had an original meaning; that is a useful thing to be able to discuss. JSON-RPC is also a useful thing to discuss. But the two things are different . It’s confusing to use the one word or phrase to mean two different things (like ‘inflammable’!). Granted, language is to some extent defined by usage: if enough people use a…

Maybe I've been educated in a strange part of the internet, but I assume that this ship already sailed ~10 years ago: when most people (90%+) hear REST, they imagine something vaguely like JSON-RPC. (and this is how ChatGPT, a sort of average of all opinions on the Internet, understands it) So if you say REST and mean something other than that, then you're committing to being misunderstood by most people.

> So if you say REST and mean something other than that, then you're committing to being misunderstood by most people.

Perhaps, but TFA is clearly written in that it is using the actual, real meaning of REST, not the value-drift corruption the laity have wrought. (The upthread comment snips out the surrounding context that brings that clarity.) Which brings us right back to the problem at hand: Potrzebie.

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

#134

Post by kyrra »

gghoop wrote: post #31

I dislike the use of gRPC within the data center. People reach for it citing performance, but gRPC is not high performance and the quality of the available open source clients is very poor, particularly outside of the core C++/Java implementations like the nodejs implementation. I am not against the use of protobuf as an API spec but it should be possible to use it with a framing protocol over TCP, there just isn't a…

The main benefit of protos is interop between various languages. If you are a single language tech stack, it matters less.

Also, if you use languages outside of Google's primary languages, you're likely not going to get as good of an experience.

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

#135

Post by ak217 »

physicles wrote: post #111
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…

> There is no difference between OpenAPI and REST, it's a strange distinction. That threw me off too. What the article calls REST, I understand to be closer to HATEOAS. > I've open sourced a Go library for generating your clients and servers from OpenAPI specs As a maintainer of a couple pretty substantial APIs with internal and external clients, I'm really struggling to understand the workflow that starts with gener…

In my part of the industry, a rite of passage is coming up with one's own homegrown data pipeline workflow manager/DAG execution engine.

In the OpenAPI world, the equivalent must be writing one's own OpenAPI spec generator that scans an annotated server codebase, probably bundled with a client codegen tool as well. I know I've written one (mine too was a proper abomination) and it sounds like so have a few others in this thread.

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

#136

Post by TheGoodBarn »

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…

Just chiming in to say we use oapi-codegen everyday and it’s phenomenal.

Migrated away from Swaggo -> oapi during a large migration to be interface first for separating out large vertical slices and it’s been a godsend.

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

#137

Post by pests »

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?

Look up HATEOS. The initial endpoint will you give you the next set of resources - maybe the user list and then the post list. Then as you navigate to say, the post list, it will have embedded pagination links. Once you have resource urls from this list you can post/put/delete as usual.

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

#138

Post by mjr00 »

ewhauser421 wrote: post #107
mjr00 wrote: post #61

Earlier quoted context omitted.

For GUI, I've been very happy with grpcui-web[0]. It really highlights the strengths of GRPC: you get a full list of available operations (either from the server directly if it exposes metadata, or by pointing to the .proto file if not), since everything is strongly typed you get client-side field validation and custom controls e.g. a date picker for timestamp types or drop-down for enums. The experience is a lot bet…

timestamppb.New(time) is hard to figure out?

> timestamppb.New(time) is hard to figure out?

No need to be snarky; that API did not exist when I started using protobuf. The method was called `TimestampProto` which is not intuitive, especially given the poor documentation available. And it required error handling which is unergonomic. Given that they switched it to timestamppb.New, they must've agreed with me. https://github.com/golang/protobuf/blame/master/ptypes/times... other exercise in terrible DX.

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

#140

Post by physicles »

mkleczek wrote: post #128
physicles wrote: post #111

Earlier quoted context omitted.

> There is no difference between OpenAPI and REST, it's a strange distinction. That threw me off too. What the article calls REST, I understand to be closer to HATEOAS. > I've open sourced a Go library for generating your clients and servers from OpenAPI specs As a maintainer of a couple pretty substantial APIs with internal and external clients, I'm really struggling to understand the workflow that starts with gener…

> This is why I created an abomination that uses go/ast and friends to generate the OpenAPI spec from the code. This is against "interface first" principle and couples clients of your API to its implementation. That might be OK if the only consumer of the API is your own application as in that case API is really just an internal implementation detail. But even then - once you have to support multiple versions of your…

I don't see why it couples clients to the implementation.

Effectively, there's no difference between writing the code first and updating the OpenAPI spec, and updating the spec first and then doing some sort of code gen to update the implementation. The end state of the world is the same.

In either case, modifications to the spec will be scrutinized to make sure there are no breaking changes.

Post reply on HN