Hacker News Reader

Comment by iudqnolq | Hacker News Reader

I don't know why JSON over HTTP gets so little love on here. It's probably the most popular option. If you don't want a resource-oriented API you don't need to throw the baby out with the bathwater and go all the way to gRPC.

View on HN

One problem that I find is that it is so unstandarized and ad-hoc beyond the network level that you basically need a complete bespoke client/parser for every API, even within larger companies if the teams are more independent. Meanwhile if you have 1 way to do gRPC or GraphQL clients they fit for anything and you can focus on what you actually want to do with the API.

GraphQL especially is excellent with this, with Apollo federation [1] allowing you to interconnect all the APIs of your complete company into 1 single endpoint and reference each other's data, which is extremely powerful and allows development to move fast if done right.

[1] https://www.apollographql.com/docs/federation/

OpenAPI?

More closely related to gRPC, Protobufs over HTTP is great too. You can then take advantage of cache-control, last-modified, etc headers in browsers and on CDNs instead of having to reimplement them. My current favorite way to make APIs is using this, and allowing user to request json as well, using a query parameter or header. This is easy to do with protojson conversion

Agreed! Had good success doing this with a toy mapping web app. Serializing polylines with Protobufs significantly reduced payload size compared to a JSON `[number,number][]` and as it was HTTP I could offload onto a CDN by setting cache-control headers.

Developer experience is also much nicer. Instead of repeatedly writing JSON serializers/deserializers on the backed + fronted you get them generated for free. I know there's various open API/json schemas code generators but for me i'd rather use Protobuf's at that point and get the benefits of a strongly typed schema, schema evolution, reduced payload size so faster experience for the user, cheaper bandwidth and cheaper storage if you currently store opaque JSON blobs in the db.

JSON API's are api's in debug mode.

You can get very close with Twirp, without losing endpoint definitions. It’s such a simple protocol you can even manually implement client wrappers or server endpoints without much difficulty.

Thanks for the suggestion, I'm considering forking that and adding support for GET requests since caching POSTs is not ideal

In other words, by using a RESTful style, with HTTP as the protocol, you get all the benefits of REST. The fact that you're using protobuf as the media type is irrelevant to the protocol.

As for the content negotiation for JSON vs protobuf, that's also defined in the HTTP standard.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ac...

That sounds like REST but more awkward to use.

What I'm referring to is what most rest APIs actually are. You mostly just use GET & POST, and urls are more arbitrary and often verbs instead of nouns. Pretty much nobody uses "true" rest.

> Pretty much nobody uses "true" rest.

[citation needed]

You're using it via your browser on this very website.

That is because HTML is intrinsically built on rest ideas. But few people develop browsers

Reply on news.ycombinator.com