[jsr339-experts] Re: Hypermedia - Take 2
+1
> -----Original Message-----
> From: Jan Algermissen [mailto:algermissen1971_at_me.com]
> Sent: Donnerstag, 4. August 2011 09:48
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: Hypermedia - Take 2
>
>
> 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