Stefan,
I think I was the one who may have kicked off this thread originally, but I
now share similar feelings as you. After thinking about for a few months,
here's some of my thoughts as to why a uniform interface may not work:
- If the resource can be represented by multiple types, how does the
client select the preferred type?
- Similarly, when a resource is created and a 201 response is returned
and the response contains multiple choices, how is a defaul type selected?
- Building on the last point, if such a client API automatically
selected a preferred type, is redirecting the client to the new location the
behavior the caller is expecting? Granted in most cases it would be, but
sometimes it may not be.
Granted these are not insurmountable issues to resolve, but I'm starting to
think that perhaps a client API should appear in JAX-RS 1.x or 2.0. In that
time, I'm sure multiple JAX-RS implementations will have experimented with
various client implementation and we can collectively learn from those
experiences.
Ryan-
On 3/7/08, Stefan Tilkov <stefan.tilkov_at_innoq.com> wrote:
>
> On Mar 7, 2008, at 5:49 AM, Bill Burke wrote:
>
> >
> >
> > Bill Burke wrote:
> >> Paul Sandoz wrote:
> >>>
> >>>>
> >>>> For a client API I was thinking more of:
> >>>>
> >>>> http://wiki.jboss.org/wiki/Wiki.jsp?page=RESTeasyClientFramework
> >>>>
> >>>> Where you could re-use jax-rs annotations and providers on an
> >>>> interface to create a proxy. What we have implemented still needs
> >>>> some work, but you probably get the gist.
> >>>>
> >>>
> >>> The key difference i see is this: the Jersey client API focuses on
> >>> the uniform interface constraint; and the RESTeasy client
> >>> framework focuses on service-specific Java artifacts.
> >>>
> >> The client API that I've done breaks the uniform interface
> >> constraint at all or focuses on connecting to a Java server. Or
> >> maybe I'm misunderstanding you? Its just the mirror opposite from
> >> server api. Instead of mapping an incoming HTTP request to a method
> >> invocation, it maps a method invocation to an HTTP request. It can
> >> pretty much invoke on any HTTP endpoint.
> >
> > LOL, sorry, I should have said the "the client API that I've done
> > *doesn't* break the uniform interface".
> >
>
>
> Logically, I believe you are right. Still: I have no idea why, but I
> share Paul's feeling that it somehow feels "wrong" on the client side
> to treat the uniform interface as an implementation detail that's
> abstracted away.
>
>
> Stefan
>
>
>
>
> > Bill
> >
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> > For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
> >
> >
>
>
>
--
Ryan J. McDonough
http://www.damnhandy.com