Complaining about JSON and then proceeding to write your API in Dart is... interesting.
Why I stopped using JSON for my APIs
131–140 of 245 posts
Re: Why I stopped using JSON for my APIs
#132I have a slight dislike for JSON+REST for API's.
The design overhead involved in determining the correct URL and HTTP method adds a layer of subjectivity to the design and bike shedding arguments.
I’m not a huge fan of Protobuf/GRPC either, if there’s a better alternative I believe RPC is the right approach for exposing APIs.
Re: Why I stopped using JSON for my APIs
#133> An API (Application Programming Interface) is a set of rules that allow two systems to communicate. In the web world, REST APIs ... are by far the most widespread.
I too had this overly restrictive view of "APIs" for too long. One I started to think about it as the interface between any teo software components it really changed the way I did programming. In other words, a system itself is composed and that composition is done via APIs. There's no point treating "the API" as something special.
Re: Why I stopped using JSON for my APIs
#134I use GraphQL. It has a higher learning curve. But it addresses the shortcomings listed by the referenced blog article. It offers type safety, efficiency and modern tooling. And it is also human readable.
If you use good tooling, you can have a mutation change a variable type in the database and that type change is automatically reflected in the middleware/backend and the typescript UI code. Not only that libraries like HotChocolate for asp.net come with built-in functions for filtering, pagination, streaming etc.
Re: Why I stopped using JSON for my APIs
#135I have never encountered the use case where the data sent by the backend over the normal CRUD operations was the bottleneck.
But we have built protobuf into a web server that handles 2 requests per second. Why? We wanted to learn about it on the job.
I think that's 99% of Protobuf usage.
Re: Why I stopped using JSON for my APIs
#136Earlier quoted context omitted.
> ASN.1, a protocol from 1984, already did what Protobuf does, with more flexibility. After working heavily with SNMP across a wide variety of OEMs, this flexibility becomes a downside. Or SNMP/MIBs were specified at the wrong abstraction level, where the ASN.1 flexibility gives mfgs too much power to do insane and unconventional things.
That's not ASN.1's fault though.
Json doesn't support comments specifically to not allow parsing directives, that means less customization. More customization of interoperability protocols is not always a good thing.
Re: Why I stopped using JSON for my APIs
#137Earlier quoted context omitted.
Yeah same, ASN.1 was a nightmare when I was dealing with LTE
I've been working on and with Kerberos and PKIX for decades. I don't find ASN.1 to be a problem as long as you have good tooling or are willing to build it. The specs are a pleasure to read -- clear, concise, precise, and approachable (once you have a mental model for it anyways). Of course, I am an ASN.1 compiler maintainer, but hey, I had to become one because the compiler I was using was awesome but not good enoug…
You just said it. You had to become compiler maintainer to make it good enough.
Re: Why I stopped using JSON for my APIs
#138"Ultra-efficient" Searched the article, no mention of gzip, and how most of the time all that text data (html, js and css too!) you're sending over the wire will be automatically compressed to...... an efficient binary format! So really, the author should compare protobufs to gzipped JSON
Re: Why I stopped using JSON for my APIs
#139Personally, I looked into protobuf for our Elixir/React Native wombocombo but the second I realized we would have to deploy app updates when we added or removed a field from the response structure it became a non-starter. I can't imagine using protobuf when you're in the first 5 years of a product.
I'm pretty sure protobuf ignores new fields (if you add; assuming you add as an append, and not change the field ordering), and it recommends you not to remove a field to ensure backward compatibility.
Re: Why I stopped using JSON for my APIs
#140> With JSON, you often send ambiguous or non-guaranteed data. You may encounter a missing field, an incorrect type, a typo in a key, or simply an undocumented structure. With Protobuf, that’s impossible. Everything starts with a .proto file that defines the structure of messages precisely. This deeply misunderstands the philosophy of Protobuf. proto3 doesn't even support required fields. https://protobuf.dev/best-pra…
Skew is an inherent problem of networked systems no matter what the encoding is. But, once the decoding is done, assuming there were no decoding errors in either case, at least with protobuf you have a statically typed object.
You could also just validate the JSON payload, but most people don't bother. And then they just pass the JSON blob around to all sorts of functions, adding, modifying, and removing fields until nobody knows for sure what's in it anymore.