[rest-practices] ID as an attribute [was Re: [deltacloud-devel] Towards declaring the Deltacloud API stable]

[Mark McLoughlin]

On Wed, 2010-05-12 at 08:32 -0400, Bryan Kearney wrote:
> On 05/12/2010 05:44 AM, Mark McLoughlin wrote:
> > On Thu, 2010-05-06 at 21:47 +0100, Mark McLoughlin wrote:
> >
> >> Related, with the RHEV-M API we're experimenting with making both the
> >> id and href attributes, which would work out nice here:
> >>
> >>    GET /api/images HTTP/1.1
> >>
> >>    <images>
> >>      <image id="1234" href="/api/images/1234"/>
> >>      <image id="9876" href="/api/images/9876"/>
> >>      ...
> >>    </images>
> >>
> >> rather than:
> >>
> >>    GET /api/images HTTP/1.1
> >>
> >>    <images>
> >>      <image href="/api/images/1234">
> >>        <id>1234</id>
> >>      </image>
> >>      <image href="/api/images/9876">
> >>        <id>9876</id>
> >>      </image>
> >>      ...
> >>    </images>
> >
> > Just wanted to bring this up again - it got lost in the mix
> >
> > I don't feel very strongly about it either way, but I do prefer:
> >
> >    POST /storagedomains/1234/attachments HTTP/1.1
> >
> >    <attachment><datacenter id="5678"/></attachment>
> >
> > over:
> >
> >    POST /storagedomains/1234/attachments HTTP/1.1
> >
> >    <attachment><datacenter><id>"5678"</id></datacenter></attachment>
> 
> 
> This may be a Java centric issue, but will the former result in json 
> which looks like:
> 
> {datacenter: {@id = "5678}}
> 
> That is kinda ugly, which is why I have tried to use elements where 
> possible. I do not remember if it was Jersey or RestEasy which did this.

It'd be nice if we avoid letting JSON mapping issues dictate the XML
design (and vice versa) ...

Is there any way to easily customize the JSON mapping so that these
attributes can be serialized like other properties?

Cheers,
Mark.