4 ms·
Ask HN: Does the world need a new API standard?
Very simply, http is meant to deliver documents for human consumption. It seems a bit strange, hacked, and unsustainable that we're forcing machines to communicate all their tasks using the same protocol. Isn't it likely that a new protocol should and will exist?
- goshx 12y agoIn practical terms, in your opinion, what are the flaws that need to be addressed by an exclusive protocol?
- tpae 12y agoI am pretty comfortable with the standards we have right now.
- valevk 12y agoWhy use a new protocol, when http is suited for the task? Or do you just want to move all the API traffic to another port?
- ilaksh 12y agoWhat I think we need is to take advantage of knowledge representation like Linked Data or Description Logics. So that information systems including APIs are described with a common machine processable semantics.
- zarriak 12y agoIt is likely that new protocols for different things will exist, but there is a much larger audience on http. Adding new protocols also opens new security holes, which really makes it easier to utilize http to your purpose than develop a new format.
- rweir 12y agono.
- room271 12y agoYou're right that HTTP is not suitable for a wide-range of tasks. There are, however, very real alternatives which people use all the time to better meet specific needs. Wikipedia has a good source of protocols used across the Internet - you'll recognise a lot as they have significant usage: https://en.wikipedia.org/wiki/Application_protocol https://en.wikipedia.org/wiki/Application_protocol
- aiiane 12y agohttp://xkcd.com/927/ http://xkcd.com/927/
- deleted 12y ago[deleted]
- PaulKeeble 12y agoWe seem to have successfully managed to make HTTP deliver different types of documents with machine targeted formats without too much difficulty. We haven't yet settled on one perfect way to do it but the protocol is flexible enough that its possible to support a very basic format negotiation. I don't currently feel that HTTP is a big problem and needs to be replaced, I am not getting angry with it, there is no real frustration in my programming associated with HTTP. It could be limiting my thinking but it doesn't feel like its con-straining what I can do.
- ClassicFarris 12y agoFor Machine <-> Machine we have several that don't use HTTP, such as Thrift, ProtocolBuffers, etc. For browser to Machine, I'm not sure we need that. The reason is, for example, we can use JSON which is very easily consumable by a machine over HTTP. HTTP provides all of the transport niceties like headers, verbs (which translate fairly well to CRUD), etc. So the combination of a fairly well featured transport layer combined with fairly well machine consumable data document format makes a pretty good protocol. Which parts can change for the better in specific relationship to a machine-centric API protocol.
- jonathaneunice 12y agoYou could level much the same criticism at most of the entire TCP/IP family. That it is stretched, pulled, prodded, and poked into all sorts of roles for which it is not especially (or especially well) designed. And yet, the aggregate experience of "the Internet" is that having a few extremely well-known, highly standardized protocols used by virtually everyone and in every possible way often trumps having "better" custom protocols. The failure of MAP/TOP, and the current dominance of common Internet protocols even in special domains against specialist protocols such as Fibre Channel and InfiniBand--it suggests you have to demonstrate something MUCH better in order for it to realistically compete against highly standardized approaches.
- shawnb576 12y agoIn short: no. Today's programmable Internet is an existence proof of this answer. In the 90s and early-2000s there were a lot of attempts to codify machine-discoverable protocols: WSDL, SOAP, etc. There are still a lot of people that are sort of obsessed with this idea. Three things have happened: (1) the weight and complexity that's come along with those protocols has been larger than the value they bring. Auto-generating proxies just isn't that helpful when you still need a human brain to figure out how to connect things together and make them useful. (2) The growth and success cloud-based apps shows that better protocols are not a necessary factor on today's Internet. This does not deny that better/faster/richer protocols could improve things, it's just not clear that's a critical-path problem. It's just not hard to look at REST docs and wire shit together, regardless if it's optimal or not. (3) Layering app-level use cases over HTTP (HATEOAS, OAUTH) works pretty well when you're navigating known domains.