Comments on: Two versions of a protocol is one too many

By: William Vambenepe — Comments on “The Good, the Bad, and the Ugly of REST APIs”

Tue, 07 Jun 2011 04:29:18 +0000

[...] disagree: Two versions of a protocol is one too many (the post behind this link doesn’t specifically discuss the JSON/XML dichotomy but its logic [...]

By: Jan Algermissen

Jan Algermissen — Tue, 16 Mar 2010 19:41:59 +0000

William,

why not use the term “HTTP-based” instead of “REST”. There is already enough confusion out there!

Jan

By: William Louth

William Louth — Tue, 02 Mar 2010 19:32:33 +0000

Something you might have overlooked is when one of the API’s introduces further abstractions (simplification for particular usage patterns) which does not preclude its implementation being layered on top of the alternative choice. There was a hint of this in the XML references but not called out directly. That said I am not in favor of people layering for the purpose of lock-in via superficial sugar candy (i.e. Spring framework) whilst hiding the underlying mechanism/technologies as well as the implications of mapping between layers – this seems to be the case for multitude of unifying cloud API’s which are incompatible themselves. A thorough cost benefit analysis should be performed in such cases but we both know that such choices are rarely based on hard evidence – too much think time required and insight needed to further implications.

By: Tim

Tim — Tue, 02 Mar 2010 16:53:16 +0000

Couldn’t agree more. Two related points:

1. One of the reasons why SQL provides such poor interoperability, promoting vendor lock-in, is that the ISO SQL committee, whenever it faced a choice of options, picked both. Thus supporting your point. XML explicitly had the goal of not having any optional features.

2. A small but significant conclusion from your argument is that protocols which support both XML and JSON are making a mistake.