3 ms·
It's a valiant effort but as someone who has dealt with unraveling a strict API built with SOAP I am going to pass. If I want something standardized I will use
by johnbellone 12y ago
It's a valiant effort but as someone who has dealt with unraveling a strict API built with SOAP I am going to pass. If I want something standardized I will use a schema based solution such as protobuf. It's already a quasi standard, has clients in many languages and is a binary protocol.
We also should not confuse an API with a transport protocol. I will tilt my hat to this not being as verbose as past attempts, but why reinvent the wheel yet again? It's not like prior attempts didn't function as expected - they did - but we in the industry chastised them for being too strict.
Let's work on improving the semantics and documentation around what constitutes an API. Swagger is an excellent example of this.
- nardi 12y agoIMO, Protobuf is at same layer as JSON, not JSON API. It's a serialization format.
- jeremyjh 12y agoIt can describe RPC services as well. https://developers.google.com/protocol-buffers/docs/proto#services https://developers.google.com/protocol-buffers/docs/proto#se...
- FractalNerve 12y agoI'm a fan of swagger, especially because it's not tied to one language and helps the developer to design his API in an easy way. The tools provided for describing your API using the Swagger spec is really fascinating. This tries to standardize API transports, which doesn't make a sense to me, because there is no need for that. If you are going to develop an API with (open) SDK clients that support consuming your services, then I don't need to care for your API transport to be written in JSON-API. Especially making transports human readable appears to be a waste of ressources in my eyes. Those API's are meant to be consumed by machines and debugging can and should be done with tools, not by enforcing a standard.