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

51–60 of 286 posts

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

#51

Post by mjr00 »

tyre wrote: post #22

> The least-commonly used API model is REST—only a small minority of APIs are designed this way brother.

Technically they're right, though; the textbook definition of REST is rare to nonexistent in my experience. What people do instead is create JSON-RPCs-over-HTTP APIs, sometimes following a REST-like URL scheme, and sometimes using different HTTP verbs on the same URL to perform different actions as one would in REST... but the API isn't really REST. The creator of REST has gone on the record multiple times about how you shouldn't call these APIs REST[0].

But in practice when most people say REST they just mean "JSON RPC over HTTP". I avoid calling things REST now and just use "JSON HTTP API" to avoid the "well, actually..." responses. (and yes, these APIs are by far the most common.)

[0] https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...

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

#52

Post by awinter-py »

lordofgibbons wrote: post #34
NAHWheatCracker wrote: post #12

My only work experience with gRPC was on a project where another senior dev pushed for it because we "needed the performance". We ended up creating a JSON API anyways. Mostly because that's what the frontend could consume. No one except for that developer had experience with gRPC. He didn't go any deeper than the gRPC Python Quick start guide and wouldn't help fix bugs. The project was a mess for a hundred reasons an…

That sounds more like a critique of the "senior" developer who didn't know grpc isn't compatible with browsers before adopting it than grpc itself.

yes who would imagine that the homegrown rpc of the internet and browser company would work on the internet and in a browser

very fair critique

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

#54

Post by AdieuToLogic »

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?

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

HAL[0] is very useful for this requirement IMHO. That in conjunction with defining contracts via RAML[1] I have found to be highly effective.

0 - https://datatracker.ietf.org/doc/html/draft-kelly-json-hal

1 - https://github.com/raml-org/raml-spec/blob/master/versions/r...

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

#57

Post by mplanchard »

eadmund wrote: post #47
tyre wrote: post #22

> The least-commonly used API model is REST—only a small minority of APIs are designed this way brother.

Real REST is a very, very small minority. Fake REST (i.e., JSON RPC) is really ridiculously common.

I’ve never liked the no true scotsman nature of REST (which is exacerbated by the fact that its canonical “specification” is a broad PhD dissertation with a lot of other concepts thrown in), so I have adopted a fairly lax definition: if your URLs are subjects and you use HTTP verbs for the verbs, I feel like it qualifies.

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

#59

Post by apayan »

nsonha wrote: post #48
lmm wrote: post #29

Earlier quoted context omitted.

> You can’t just give someone a simple command to call an endpoint—it requires additional tooling that isn’t standardized. GRPC is a standard in all the ways that matter. It (or Thrift) is a breath of fresh air compared to doing it all by hand - write down your data types and function signatures, get something that you can actually call like a function (clearly separated from an actual function function - as it shoul…

> GraphQL is even better just a casual sentence at the end? How about no. It's in the name, a query-oriented API, useless if you don't need flexible queries. Why don't you address the problem they talked about, what is the cli tool I can use to test grpc, what about gui client?

grpcurl is what I use to inspect gRPC apis.

https://github.com/fullstorydev/grpcurl

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

#60

Post by [deleted] »

nsonha wrote: post #48
lmm wrote: post #29

Earlier quoted context omitted.

> You can’t just give someone a simple command to call an endpoint—it requires additional tooling that isn’t standardized. GRPC is a standard in all the ways that matter. It (or Thrift) is a breath of fresh air compared to doing it all by hand - write down your data types and function signatures, get something that you can actually call like a function (clearly separated from an actual function function - as it shoul…

> GraphQL is even better just a casual sentence at the end? How about no. It's in the name, a query-oriented API, useless if you don't need flexible queries. Why don't you address the problem they talked about, what is the cli tool I can use to test grpc, what about gui client?

[deleted]
Post reply on HN