3 ms·

I could be misunderstanding of course, but IMO this article is basically misleading or incorrect. If everything else is the same, a JSON API is strictly more fl

I could be misunderstanding of course, but IMO this article is basically misleading or incorrect. If everything else is the same, a JSON API is strictly more flexible than the corresponding HTML API because JSON is a strictly more flexible serialization format than HTML. You have a database on one side of a network and clients on the other side. If you bind your data to a specific client on the database side of the network, your system is less flexible. N.B. I am not making any claims about whether any particular HTTP API should serve JSON or HTML, I’m just saying that JSON is a strictly more flexible option.

bruce511 3y ago
Yes and no. What I'm reading [1] is that they're advocating for side-by-side decoupling. In other words, humans and computers need different interfaces. Rather than try and build one, which is bad for both [2] build 2, one for the humans (however you prefer) and one for the computers (REST API). Perhaps I'm reading it this way because I'm prejudiced, (I've written our systems this way) and it seems to be working well. [1] this whole article is both well formatted, and seems to make a good post, but equally seems to feel like you're not sure what it's trying to say. Perhaps it makes more sense in context,rather than as a stand-alone article. [2] the computer-client team has different needs to the human-client team. One wants a very stable API, the other wants regular changes. One is content driven, the other process driven. Ultimately they want different things making two interfaces makes both teams happier with less conflict between them that you have to umpire.
vlz 3y ago
True, the JSON API itself is more flexible, in the sense of being multi-purpose and more easily consumable by different clients. But how easy is it to change each API? I think the article uses "flexibility" as our flexibility to change the API, not as the flexibility of the data.
- killthebuddha 3y ago
  I think this makes sense and my initial comment may have been incorrect. I guess the idea is something like: - a general purpose API is insufficient for any particular application, each application will require a special-purpose API alongside the general API - assuming that you are going to have an application-specific API, it makes sense that the application-specific API should serve data specifically-tailored to that application (in this case hypermedia) That said, it seems like the most interesting discussion would be about the tradeoffs between the two-JSON-API solution that they reference and the one-JSON-API + one-HTML-API solution that they suggest.

bruce511 3y ago

Yes and no. What I'm reading [1] is that they're advocating for side-by-side decoupling. In other words, humans and computers need different interfaces. Rather than try and build one, which is bad for both [2] build 2, one for the humans (however you prefer) and one for the computers (REST API). Perhaps I'm reading it this way because I'm prejudiced, (I've written our systems this way) and it seems to be working well. [1] this whole article is both well formatted, and seems to make a good post, but equally seems to feel like you're not sure what it's trying to say. Perhaps it makes more sense in context,rather than as a stand-alone article. [2] the computer-client team has different needs to the human-client team. One wants a very stable API, the other wants regular changes. One is content driven, the other process driven. Ultimately they want different things making two interfaces makes both teams happier with less conflict between them that you have to umpire.

vlz 3y ago

True, the JSON API itself is more flexible, in the sense of being multi-purpose and more easily consumable by different clients. But how easy is it to change each API? I think the article uses "flexibility" as our flexibility to change the API, not as the flexibility of the data.

killthebuddha 3y ago
I think this makes sense and my initial comment may have been incorrect. I guess the idea is something like: - a general purpose API is insufficient for any particular application, each application will require a special-purpose API alongside the general API - assuming that you are going to have an application-specific API, it makes sense that the application-specific API should serve data specifically-tailored to that application (in this case hypermedia) That said, it seems like the most interesting discussion would be about the tradeoffs between the two-JSON-API solution that they reference and the one-JSON-API + one-HTML-API solution that they suggest.