Hold on :-) Please don't try to prove me that in the example you listed relative URIs are better, it's obvious, isn't it ?
I can easily come up with the example which will show that for many realistic payloads the actual links will consume a very small percentage,
just don't have time for a ping-ball game really.
Can you type a bit the client code which consumes those links ? I nearly bet you won't match the simplicity of code dealing with absolute URIs.
Of course, UriBuilder can help on the client side, but simpler clients will also have to do those ugly checks like 'if ends with / and starts with / then do this otherwise that'
Sergey
________________________________________
From: Markus KARG [markus_at_headcrashing.eu]
Sent: 03 August 2011 18:09
To: jsr339-experts_at_jax-rs-spec.java.net
Subject: [jsr339-experts] Re: Hypermedia - Take 2
> > +1. Absolute as a default is obviously more interoperable (or
> portable, to use your terminology).
> >
> >> S.B - I actually did not mean 'portable', it just got typed out
> somehow and then I realized I actually meant 'interoperable' :-)
>
> FWIW, on a second thought, Jan may have a valid point here - relative
> links may be significantly more efficient esp.
> when used as part of small message payloads. Having "workaround" the
> option for ill-behaved clients may be good enough
> and we may not need to trade the default efficiency for interop in this
> case.
>
> S.B. That's OK.
> Personally, the idea of writing the client code which checks the links
> and then goes and builds absolute URIs as opposed to doing immediate
> GET
> makes me a bit nervous, especially that I will probably write not a
> very good server code which will 'cost' WEB extra "http://myhost.com"
> per link :-)
> But of course it's up to a concrete application code which does decide
> to use @Ref on which form the links should take, so I'm going to
> support
> whatever decision the group takes
Imagine your payload is a shopping cart that contains 10 articles. Each
article is described just by a URI pointing to the full description.
<Cart>
<Item
href="
http://api.genericshopshoftware.info/shops/supercheapelectronics/shopp
ingcart/items/0" />
<Item
href="
http://api.genericshopshoftware.info/shops/supercheapelectronics/shopp
ingcart/items/1" />
<Item
href="
http://api.genericshopshoftware.info/shops/supercheapelectronics/shopp
ingcart/items/2" />
<Item
href="
http://api.genericshopshoftware.info/shops/supercheapelectronics/shopp
ingcart/items/3" />
<Item
href="
http://api.genericshopshoftware.info/shops/supercheapelectronics/shopp
ingcart/items/4" />
<Item
href="
http://api.genericshopshoftware.info/shops/supercheapelectronics/shopp
ingcart/items/5" />
<Item
href="
http://api.genericshopshoftware.info/shops/supercheapelectronics/shopp
ingcart/items/6" />
<Item
href="
http://api.genericshopshoftware.info/shops/supercheapelectronics/shopp
ingcart/items/7" />
<Item
href="
http://api.genericshopshoftware.info/shops/supercheapelectronics/shopp
ingcart/items/8" />
<Item
href="
http://api.genericshopshoftware.info/shops/supercheapelectronics/shopp
ingcart/items/9" />
</Cart>
Now we do the same relative.
<Cart>
<Item href="0" />
<Item href="1" />
<Item href="2" />
<Item href="3" />
<Item href="4" />
<Item href="5" />
<Item href="6" />
<Item href="7" />
<Item href="8" />
<Item href="9" />
</Cart>
I think this spares rather lot of bandwith (just calculate the percentage if
you like -- visually it looks like saving 75%), so few more complexity in
the code pays off very soon (I don't know about your's, but my bandwidth is
rather expensive).