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

91–100 of 286 posts

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

#91

Post by danpalmer »

pianoben wrote: post #71
danpalmer wrote: post #26

Earlier quoted context omitted.

I also disagree, at Google everything is RPCs in a similar way to gRPC internally, and I barely need to think about the mechanics of them most of the time, whereas with REST/raw HTTP, you need to think about so much of the process – connection lifecycle, keepalive, error handling at more layers, connection pools, etc. However, I used to work in a company that used HTTP internally, and moving to gRPC would have sucked…

The flexibility of HTTP has advantages, too; it's simple to whip up a `curl` command to try things out. How does Google meet that need for gRPC APIs?

There's a curl for RPCs internally. It helps too that RPC servers are self describing, so you can actually list the services and methods exposed by a server. I'd say it's much simpler than curl, although again that's in large part because there's a lot of shared infra and understanding, and starting from scratch on that would be hard.

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

#92

Post by hedora »

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…

The biggest project I’ve used it with was in Java.

Validating the output of the bindings protoc generated was more verbose and error prone than hand serializing data would have been.

The wire protocol is not type safe. It has type tags, but they reuse the same tags for multiple datatypes.

Also, zig-zag integer encoding is slow.

Anyway, it’s a terrible RPC library. Flatbuffer is the only one that I’ve encountered that is worse.

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

#93

Post by silisili »

mvdtnz wrote: post #82
silisili wrote: post #17

Earlier quoted context omitted.

You're being way too polite. The article is garbage and completely incorrect about what REST and OpenAPI even are.

You're wrong. The author is using "REST" to mean an API at Level 3 on the Richardson Maturity Model[0] - this was the original conception of what it meant to be a "REST API" before the wider internet decided "REST" meant "nice looking URLs". What he refers to as "OpenAPI APIs" could be called Level 2 Web APIs on the same model. He uses "REST" correctly. He uses "OpenAPI" as a shorthand for the class of web APIs that…

I could concede perhaps he wasn't necessarily wrong on REST, though I personally think it's pedantic and incorrect, regardless of what the creator of the term says. Things evolve, and returning a list of objects instead of a list of links was an obvious progression, since spamming 1000s of GET requests doesn't scale well in the post 90s. If the industry at large generally agrees on what makes an API restful, it feels like we should accept such evolution.

OpenAPI is a description language and has little to do with an API itself. It's documentation. People were using 'unpure' REST long before it or Swagger even existed. And as the parent pointed out, you can add an openapi spec later, and it doesn't magically change the API itself.

Further, it creates a weird circular logic that doesn't work.

From https://swagger.io/docs/specification/v3_0/about/ -

"OpenAPI Specification (formerly Swagger Specification) is an API description format for REST APIs"

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

#95

Post by TeeWEE »

hedora wrote: post #92
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…

The biggest project I’ve used it with was in Java. Validating the output of the bindings protoc generated was more verbose and error prone than hand serializing data would have been. The wire protocol is not type safe. It has type tags, but they reuse the same tags for multiple datatypes. Also, zig-zag integer encoding is slow. Anyway, it’s a terrible RPC library. Flatbuffer is the only one that I’ve encountered that…

What do you mean with validating the bindings? GRPC is type safe. You don’t have to think about that part anymore.

But as the article mentions OpenAPI is also an RPC library with stub generation.

Manual parsing of the json is imho really Oldskool.

But it depends on your use case. That’s the whole point: it depends.

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

#96

Post by ctxc »

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…

Thank you for the summary! :)

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

#97

Post by whoevercares »

reactordev wrote: post #69
NAHWheatCracker wrote: post #45

Earlier quoted context omitted.

Correct, I wasn't critiquing gRPC. I was critiquing a type of person who might push for gRPC. That developer probably thought of it as a novelty and made up reasons to use it. It was a big hassle that added to that teams workload with no upside.

When all you have is a hammer… gRPC is fantastic for its use case. Contract first services with built in auth. I can make a call to a service using an API that’s statically typed due to code generation and I don’t have to write it. That said, it’s not for browsers so Mr gRPC dev probably had no experience in browser technologies. A company I worked for about 10 years ago was heavy gRPC but only as a service bridge th…

gRPC is indeed for backend service to service calls with strong contract/model first approach. It’s important for company in serious API and SDK vending business.

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

#98

Post by oppositelock »

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 is a way of documenting the behavior of your HTTP API. You can express a RESTful API using OpenAPI, or something completely random, it's up to you. The purpose of OpenAPI is to have a schema language to describe your API for tooling to interpret, so in concept, it's similar to Protocol Buffer files that are used to specify gRPC protocols.

gRPC is an RPC mechanism for sending protos back and forth. When Google open sourced protobufs, they didn't opensource the RPC layer, called "stubby" at Google, which made protos really great. gRPC is not stubby, and it's not as awesome, but it's still very efficient at transport, and fairly easy too extend and hook into. The problem is, it's a self-contained ecosystem that isn't as robust as mainstream HTTP libraries, which give you all kinds of useful middleware like logging or auth. You'll be implementing lots of these yourself with gRPC, particularly if you are making RPC calls across services implemented in different languages.

To me, the problem with gRPC is proto files. Every client must be built against .proto files compatible with the server; it's not a discoverable protocol. With an HTTP API, you can make calls to it via curl or your own code without having the OpenAPI description, so it's a "softer" binding. This fact alone makes it easier to work with and debug.

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

#99

Post by hedora »

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…

There’s also a gaping security hole in its design.

They don’t have sane support for protocol versioning or required fields, so every field of every type ends up being optional in practice.

So, if a message has N fields, there are 2^N combinations of fields that the generated stubs will accept and pass to you, and its up to business logic to decide which combinations are valid.

It’s actually worse than that, since the other side of the connection could be too new for you to understand. In that case, the bindings just silently accept messages with unknown fields, and it’s up to you to decide how to handle them.

All of this means that, in practice, the endpoints and clients will accumulate validation bugs over time. At that point maliciously crafted messages can bypass validation checks, and exploit unexpected behavior of code that assumes validated messages are well-formed.

I’ve never met a gRPC proponent that understands these issues, and all the gRPC applications I’ve worked with has had these problems.

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

#100

Post by whoevercares »

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…

There was a talk in 2023 of a non-TCP based protocol, Homa in RPC for data center use-case https://youtu.be/xQQT8YUvWg8?si=g3u5TogBe0_QpPpj.
Post reply on HN