On Aug 4, 2011, at 1:07 AM, Bill Burke wrote:
> ARe there really any sophisticated REST client APIs for other languages? I guess what i'm saying is that Sergey has a point. While we can build in some nice client-side support for relative links, other languages might not have that capability and it would be easier for them to code against absolute links. What does it look look in Javascript? Can you take advantage of relative links easily there?
What I do not really understand is how you can even think about implementing an HTTP client (which means essentially implementing RFC 2616 and RFC 3986) and not implement the handling of relative URTI references right in the core code? It is a core aspect of RFC 3986, the algorithm is written down in the RFC and it should take a decent programmer just a tiny fraction of the time it takes to implement the rest of the RFCs anyway.
Where is the whole point in *not* supporting relative URI reference handling in an HTTP client? What is the advantage?
But the bottom line for me is really that making absolute URI references a default will only encourage client writers to skip relative URI reference handling and this will make the situation worse instead of point implementors in the right direction.
To me, prominent frameworks always have a responsibility because they have an educational character.
As in "See, JAX-RS 2.0 makes relative URI references the default. You better not skip that stuff in your client code". Instead of "Nah - handling relative URI references is not so important. Look at RAX-RS 2.0. There, absolute URI references are the default. Must be right then not to worry."
Frameworks can help people to learn the right stuff but they can equally lead people to learn (and spread) the wrong stuff. Especially in the case of REST the is so much mis-information and I think REST frameworks should help cure (instead of enforce) that misinformation.
I find there is great responsibility for groups like this one and this responsibility is what matters most (to me) regarding the design decisions we make.
Jan
>
> On 8/3/11 4:12 PM, Sergey Beryozkin wrote:
>> 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).
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com