5 ms·

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

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.

chocolatkey 4y ago
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
- tiew9Vii 4y ago
  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.
- dontlaugh 4y ago
  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.
  - chocolatkey 3y ago
    Thanks for the suggestion, I'm considering forking that and adding support for GET requests since caching POSTs is not ideal
- rswail 4y ago
  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/Accept https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ac...
dtech 4y ago
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/ https://www.apollographql.com/docs/federation/
- throwawaymaths 4y ago
  OpenAPI?
charcircuit 4y ago
That sounds like REST but more awkward to use.
- iudqnolq 4y ago
  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.
  - rswail 4y ago
    > Pretty much nobody uses "true" rest. [citation needed] You're using it via your browser on this very website.
    - afiori 4y ago
      That is because HTML is intrinsically built on rest ideas. But few people develop browsers

chocolatkey 4y ago

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

tiew9Vii 4y ago
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.
dontlaugh 4y ago
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.
- chocolatkey 3y ago
  Thanks for the suggestion, I'm considering forking that and adding support for GET requests since caching POSTs is not ideal
rswail 4y ago
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/Accept https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ac...

dtech 4y ago

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/ https://www.apollographql.com/docs/federation/

throwawaymaths 4y ago
OpenAPI?

charcircuit 4y ago

That sounds like REST but more awkward to use.

iudqnolq 4y ago
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.
- rswail 4y ago
  > Pretty much nobody uses "true" rest. [citation needed] You're using it via your browser on this very website.
  - afiori 4y ago
    That is because HTML is intrinsically built on rest ideas. But few people develop browsers