How JSON over HTTP Services Fits into Distributed Systems

Distributed Services with Go — by Travis Jeffery (9 / 84)

👈 Chapter 1 Let’s Go | TOC | Set Up the Project 👉

JSON over HTTP APIs are the most common APIs on the web, and for good reason. They’re simple to build since most languages have JSON support built in. And they’re simple and accessible to use since JSON is human readable and you can call HTTP APIs via the terminal with curl, by visiting the site with your browser, or using any of the plethora of good HTTP clients. If you have an idea for a web service that you want to hack up and have people try as soon as possible, then implementing it with JSON/HTTP is the way to go.

JSON/HTTP isn’t limited to small web services. Most tech companies that provide a web service have at least one JSON/HTTP API acting as the public API of their service either for front-end engineers at their company to use or for engineers outside the company to build their own third-party applications on. For their internal web APIs, the company may take advantage of technologies like protobuf for features that JSON/HTTP doesn’t provide — like type checking and versioning — but their public one will still be JSON/HTTP for accessibility. This is the same architecture I’ve used at my current and previous companies. At Segment we had a JSON/HTTP-based architecture that for years handled billions of API calls a month before we changed our internal services to use protobuf/gRPC to improve efficiency. At…