[occi-wg] Votes: XML vs. JSON vs. TXT
Marc-Elian Bégin
meb at sixsq.com
Thu May 7 13:33:33 CDT 2009
Correct me if I'm wrong but I understand that the service we're
considering here is a RESTFul web-service, and further following a
resource oriented architecture (see Ruby and Richardson's RESTFul Web
Services book).
In any generic RPC protocol, you need to define verbs and messages
(methods and parameters). With RESTFul and ROA, since we're
manipulating resources, the HTTP verbs (GET, PUT, POST, DELETE, etc)
provide a pretty clear semantic. So what's left is the messages that
are exchanged between the client and the server.
Another observation is that, and this is based on my personal
experience so feel free to contradict me, with 'big web-services' à la
SOAP, the only way to reach interoperability between SOAP (and WSDL)
tooling is to keep thing really simple (and stay away from the WS-*
stuff as much as possible). And even armed with amazingly advanced
tooling, the in order to reach interoperability, the messages
(parameters) have to be simple... otherwise the cost of
interoperability goes up... and fast.
So we need to keep the messages simple.
As a user of the service, I want to be able to paste in my browser the
url to a resource and get something I understand, which means (X)HTML,
with the right hyperlinks to the resource's neighbours and possible
actions I can perform on these resources... right there in my
browser! But if I'm a javascript, I probably want JSON or text. And
if I'm Excel, I probably want CSV or text. And if I'm Python or Java,
XML works. And if I don't like any of these, I grab the XML and
transform it on the fly into something I like.
I know, we're not in a design room in front of a white board... we're
trying to define a standard, but I think it's important to set the
scene in terms of implementation so that we know more or less what the
real thing's going to look like.
Getting back to your question... I think that to be successful, OCCI
Web Services will have to embrace the reality of today's web, which is
to support a number of content-types. And while I do realise that
from a standardisation point-of-view I'm suggesting to raise the bar a
little for v1.0, I don't think it's a problem. And the reason for
that is 'simplicity'. So if we're finding that our life becomes
difficult in specifying the messages in XML, JSON and TEXT, then we
might want to re-evaluate our complexity level.
Having said all that, we can start with one language and add others as
we go along. But then the choice become which one's first. The
argument against XML is that we can very quickly throw complexity
which will bite us later when
we try to express the same in a simpler language. On the other hand,
we can start with TEXT or JSON to mitigate that risk, but then it's
more work to transform.
Perhaps to finish... and in good SCRUM fashion... why don't we let who
ever has spare cycles produce a naive implementation of what we've got
now, in whatever his/her prefer language, and we look at it together!
If we don't like it, we throw it away and start again... but we'll
have learned something. But this is only possible if we take small
steps at a time, otherwise it hurts to throw too much away... and pain
is not fun!!
To conclude... I think we need to keep things simple... and if it's
simple it won't be a problem to support a wide range of content-
types. If we don't want to do them all right away, but want to keep
the complexity beast at bay... we should then take small steps, have a
look at a running system, make sure it implements the spec properly,
realign and start again.
Cheers,
Meb
PS. In doubt... write code ;-)
On May 7, 2009, at 6:56 PM, Tim Bray wrote:
> On May 7, 2009, at 1:12 AM, Marc-Elian Begin wrote:
>
>> I'm currently using restlet to build RESTFul web-services (very
>> nice by
>> the way) in Java. In such a framework, generating the requested
>> format
>> based on the requests's 'Content-Type' attribute is trivial (as
>> long as
>> the transformation is available). This means that my WS can talk
>> (x)html when the user's a human (me), or XML or JSON or plain/text.
>>
>> So for me multi-format is mandatory...
>
> Could you expand on you you get from "Generating multiple formats is
> easy for me based on my implementation tools" to "multi-format is
> mandatory"?
>
> The intervening steps in the argument are not self-evident. -T
>
More information about the occi-wg
mailing list