Proposal: Query Parameter for "Compact" Representations

  4 posts   Feedicon  
Replies: 3 - Last Post: September 24, 2009 04:39
by: yadieet
showing 1 - 4 of 4
 
Posted: September 22, 2009 20:37 by Craig McClanahan
In VDCS with large numbers of VMs, the size of the overall VDC representation, as well as particular Clusters, can be quite large. To allow clients a choice, it is proposed that a "compact" query parameter, with a boolean value, would be included on the "Get VDC" and "Get Cluster" requests (with a default value of "false"). If set to true, the returned representation of child cluster/VM/VNet/PublicAddress objects would be sparse, including only the "name" and "uri" fields. This is enough information for the client to decide they might be interested in this particular object, and provides a URI to which a GET operation can be performed to get the entire representation.

Craig
 
Posted: September 23, 2009 17:05 by Tim Bray
I think this one is problematic in theory and in practice. This change reduces implementors' freedom to design their URI spaces; I could not use a naming scheme for VMs such as /vms?cluster=37&machine=2 without worrying about running into this or some future query clause.

Also, we end up having two names for the same thing: URI-of-VDC vs. URI-of-VDC?compact=true. Thus, this is sure to get the RESTafarians grumbling in their beards, because RFC3986 is perfectly clear that the ?-query part of the URI is actually part of the identifier unlike the #-fragment part, and I think they have a point.

I have an alternate proposal. What we have is a resource, say a VDC, and we want to request varying representations of it. The HTTP idiom for doing this is the Accept header. I'm not proposing that we make any new media-types, but rather just add an optional parameter to each of our media-types (See RFC2616, sections 3.6 and 3.7).

So if you do a GET on a VDC with:

Accept: application/vnd.com.sun.cloud.VDC+json

you get the full dump, but if you say:

Accept: application/vnd.com.sun.cloud.VDC+json;compact=true

You get just the compact representation. I don't think this adds any work in particular to either the server or client side; manipulating Accept headers is about the same degree of difficulty as manipulating URI segments.

BTW, there's another proposal that every resource model have a "description" field, which seems reasonable to me. If we adopt that, then maybe the compact form should have name/uri/description?
 
Posted: September 23, 2009 20:34 by afrank
I think the suggestion to use an optional parameter to extend the media-type makes sense, but I would like to suggest that

  • the "compact" representation should be the default representation and
  • use "format" instead of "compact" as parameter to support additional representations.


E.g.: to get the "full" representation, you would use:

Accept: application/vnd.com.sun.cloud.VDC+json;format=full
 
Posted: September 24, 2009 04:39 by yadieet
I think it's not really important to use 'boolean:compact' parameter.
Let it representing formal full name.
Replies: 3 - Last Post: September 24, 2009 04:39
by: yadieet
  • Mysql
  • Glassfish
  • Jruby
  • Rails
  • Nblogo
Terms of Use; Privacy Policy;
© 2010, Oracle Corporation and/or its affiliates
(revision 20120127.ac94057)
 
 
Close
loading
Please Confirm
Close