On Thu, 2011-11-03 at 08:56 -0400, Tong Li wrote:
> In my previous implementation, request with body are always in xml format,
> it was never in a HTML form post. The reason was that DMTF spec did not
> really care HTML. All forms of requests should be in theory the
> content-type of application/CIMI-<ResourceType>+xml or
> application/CIMI-<ResourceType>+json. When I implemented the client to
> produce the request, I did not add that header, because I was not sure if
> add that header will actually break Sinatra so it may not be able to
> determine if the request is actually for xml or json.
That's actually a very good point: these custom MIME types are a pain in
the neck. They break the default behavior of any
dispatch-by-content-type framework, and require some manual fiddling to
get it back on track.
In Deltacloud, we generate the response with the following (in Rails,
the code would look exactly the same):
respond_to do |format|
format.xml { .. generate XML output .. }
format.json { .. generate JSON output .. }
end
With the custom MIME types in the Accept header, the above doesn't work
out of the box - we painstakingly have to teach the framework that
application/CIMI-Foo+xml is really application/xml, and
application/CIMI-Foo+json is application/json.
The purported gain of being able to dispatch on/know what is being asked
for is not there. To me the whole thing is a little bit like replacing
image/png with image/passport-pic+png, image/soccer-team+png,
image/kittens-in-a-pile+png, etc.
If there ever is a need for the client to select the representation of a
resource by type, this can be done through media type parameters, i.e.
the client could send
Accept:
application/xml;type=BriefMachine,application/xml;q=0.8;type=FullMachine
But I don't really see a need for that - there is only ever one CIMI
Type that comes back from a request, and I don't believe that the
flexibility of choosing between types will really help implementors.
David
