On Apr 12, 2007, at 9:01 PM, 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?
>
Independent of deployment infrastructure.
> > 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).
>
Exactly, we should try to meet the 80% with a high level easy to use
API, the other 20% can be ugly but functional.
> > 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 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.
>
> 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'm not sure I follow all the nuances of this aspect of the
discussion. In my view we are trying to produce an API that makes it
easy to build RESTful services, we aren't trying to build a REST API.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.
- application/pkcs7-signature attachment: smime.p7s