On Apr 13, 2007, at 3:01 AM, Dhanji R. Prasanna wrote:
>
>
> On 4/13/07, Stefan Tilkov <stefan.tilkov_at_innoq.com> wrote:
>
> The JSR text could be misread to mean "independent of underlying
> technology (HTTP, WS-*, ...) which I definitely hope nobody here
> wants.
>
> I thought it meant independent of underlying deployment
> infrastructure ( i.e. servlet, restlet, JAX-WS containers...). Marc/
> Paul can you shed some light?
>
> > If the goal was to use a traditional style of programming using
> > classes,
> > then we could just require people to:
> > - have all resources extend a base Resource class
> > - have all representations extend a base Representation class
> >
>
> I don't see this as a conflict. Why can't the API use a "traditional
> model" (I didn't even know OO had become traditional yet) and use
> annotations wherever they make things easier?
>
> Sounds sensible to me. Im also not clear on what the difference is
> between mapping an object and mapping a graph of objects (are we
> talking about cascading mapping semantics a la JPA?).
>
> "The goal of this JSR is to provide an easy to use, declarative style
> of programming using annotations for developers to write REST ful Web
> Services and also enable low level access in cases where needed by
> the application."
>
> My understanding was that this means that access to every "low-level"
> feature is possible in a standardized way.
>
> Yes, but I read that as being in the exceptional case (i.e. where
> the declarative, high-level api can't cut it).
>
Fine with me :-)
> > I think that our main concern should be: how can we express the
> > mapping from
> > POJOs to RESTful Web services in the most compelling and in less
> > intrusive
> > ways, while supporting the important high-level Web/HTTP features
> > found in
> > RESTful applications (caching, stateless, identification by URIs,
> > uniform
> > interface, content negotiation, etc.).
> >
>
> Just as a matter of personal opinion, I would be very disappointed if
> this was all JSR 311 achieves. I don't want to see POJOs mapped to
> RESTful Web services; I want to see a good and standardized
> programming model for building RESTful HTTP applications in Java.
> Easy things should be easy and hard things possible.
>
> I am curious what you mean by "building RESTful HTTP applications
> in Java."
> RTF has already said something to the effect that he doesnt believe
> in such a thing as a REST application (i.e . built on a "REST"
> API). I agree in that I dont believe it's a programming model (like
> MVC or something).
>
I agree it's not a programming model. To phrase what I meant
differently, I want to be able to implement any RESTful API using JSR
311. In the WS-* world, there's the concept of contract-first vs.
code-first development, i.e. do I start from the Java code and
generate a WSDL from it, or do I design the WSDL first and generate
Java from it. (In my personal opinion, the best approach is to not
generate at all, but I digress).
The analogy to our case is that I do not want to be restricted to
being able to expose POJOs RESTfully, i.e. I do not want to forced to
start from the code, and limit what I can do to the conventions we
end up building. I agree the latter is useful for the majority of
cases, but there *must* be a way to achieve the 20% case as well.
> I ask this mainly because some of the comments on the Yahoo REST
> mailing list seemed to push for using jsr311 to build *better* HTTP
> support in java (ostensibly to supercede servlet, URLConnection et
> al). I am not sure if you were one of those commentors, Stefan.
I think I was, yes, although I would not go as far as to suggest
replacing everything there is - that would obviously not be doable.
In my initial discussions with Paul (before joining), I understood
that it's not unreasonable to expect that there may result some
change requests to e.g. the Servlet API from this JSR.
>
> This would be a diametrically opposed goal to building a high-level
> abstraction for web services that use POJOs (I hesitate to say in
> the "restful" style--but stateless, transparently layered,
> cacheable, uniformly locateable, you get the picture...), which I
> assume is the goal for the JSR regardless of whatever else we hope
> to achieve?
>
I don't know. Is it? One of my favorite examples of a RESTful API (in
the Web API sense, not a programming model API sense) is the
Blinksale API:
http://www.blinksale.com/api
I'm not affiliated with those guys in any way, but let's for the sake
of the argument assume that I need to implement this Web API exactly
as it's described, using Java. Can I do so? Using JSR 311? Or only if
I access the underlying "container"?
It seems Restlet's goal is to enable building any kind of RESTful
HTTP app. Jérome seems to see JSR 311 as a lightweight, high-level
API on top of Restlet (as one possibility); from this perspective,
it's OK if JSR 311 isn't sufficient for everything, and it's "wrong"
if 311 does something Restlet can already do (at least that's my
understanding). I believe making JSR 311 self-sufficient is
preferable. I see no reason why (as has been suggested) Restlet
classes that overlap can't be candidates to be "pulled into" the JSR
for standardization.
>
> I'm not at all sure I like the RESTlet API, which is quite likely
> because I still haven't looked at it ihn detail. But I would
> definitely welcome it as one possible starting point for this JSR,
> just as much as the current proposal from Marc and Paul.
>
> I agree (in welcoming RESTlet as a starting point). I dont have any
> experience with it either so can't comment about it.
>
> Jerome, what is it that you feel jsr311 should do that Restlet
> doesnt (or vice-versa) and what are your reasons for keeping them
> separate?
>
> Again, if the stated goal of this JSR is "define a good mapping of
> POJOs to RESTful Web services", this seems just as backwards to me as
> most of the JAX-WS stuff.
>
> Im not sure I understand what this means. =)
This is linked to the same argument as above (code-first vs. contract-
first), but I don't really want to get into a JAX-WS discussion; I
officially retract that statement :-)
Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/