On Apr 11, 2007, at 4:09 AM, Jerome Louvel wrote:
>
>> The same applies to use of Entity<T>, Representation<T> and
>> Response.
>> You only use them when you need them, the rest of the time you can
>> work with POJOs. However when you do need them they bring together
>> everything in one place and IMO are much more convenient and
>> intuitive than sprinkling a set of annotated properties representing
>> aspects of the request and response through the method signature and
>> class.
>
> I understand your motivation. Still, the problem I have with
> Response (and
> Representation to a lesser extent) is that it makes the user focus
> shift
> from POJO resources to lower-level request/response flows.
>
> If you give him access to a Response object, why not also give
> access to a
> Request object and then why not let him directly handle the Request/
> Response
> call?
You'll note that the API does exactly that ;-).
> Then you have defined another Servlet-like API that follows two
> opposite goals: exposing higher-level domain objects as Web
> resources AND
> providing a complete, flexible and optimized request/response
> handling API
> (similar to the Servlet API or Restlet API but not as complete and
> useful).
>
> I strongly disagree to go down this road as this will lead to
> confusion and
> suboptimal design. I have the feeling that you do want to cover
> 100% of the
> HTTP use cases with this JSR instead of truly attempting to make
> the 80%
> simpler cases truly easy to implement while keeping the JSR small,
> focused
> and easy to learn.
>
I do want to make the 80% cases truly easy to implement using our API
but I also think its important to have an escape hatch to implement
the other 20%. As I wrote elsewhere, it might make sense to just
inject some container-specific artifact to cover the 20%.
You give the impression of wanting to define the 80% in terms of what
is achievable using annotations alone. I strongly disagree with that
- annotation driven doesn't mean annotation-only. I think developer
productivity and ease of use is key, annotations are an important
aspect of that but they can also get in the way if you try to use
them for everything - sometimes a class or interface just works better.
> As soon as I try to propose a simplification for the benefit of
> reducing the
> API conceptual weight you object because it isn't flexible enough
> and can't
> handle the rare cases where you don't have control on the source
> code and
> want to do advanced things (like tweaking the HTTP headers, fine
> tuning the
> cache control, etc.).
I don't see working with HTTP headers and cache control as advanced
or edge cases, I think those are important capabilities. I also think
we may disagree on what is rare sometimes, possibly due to a
different mental model of resource classes, more on that below.
> I still don't see the point of asking this JSR to
> handle cases where you can't annotate a resource POJO class because
> you
> don't control the source code. For the representation classes this
> is less
> an issue as we talked about (the wrapper thing).
>
I think there may be some misunderstanding here. I've never suggested
that a resource POJO (i.e. the class whose methods get called to
service HTTP methods) wouldn't be editable, only the classes that map
to HTTP entities. I think where we differ is that you seem to assume
that there will usually be classes that map to representations
whereas I think that resource class methods should be able to work
directly with standard classes. I.e. I see methods like
@HttpMethod
@ProduceMime("text/plain")
String getSomething() {...}
whereas you seem to see methods like
@HttpMethod
SomethingRepresentation getSomething() {...}
public class SomethingRepresentation {
...
public String getValue() {...}
}
>
>> BTW, in the above suggestion, how would the post method set
>> the value
>> of {var} ?
>
> As we need an annotation to inject context info into POJO, we also
> need a
> mechanism to let POJOs update some context info. I am open about
> having an
> optional Context class that would serve as a gateway between the
> annotated
> POJOs and their environment. I would limit this gateway to this
> sole class
> with no Request or Response classes, even though useful information
> could be
> available (like the IP address of the client). This could be a good
> abstraction of the lower-level HTTP request/response cycle into a
> higher-level concept.
>
You mean something like:
public MyResource {
@Resource
Context ctx;
@Redirect("/target/{var}")
public @Status int post(InputStream data) {
...
ctx.setRedirectParam("var",somePath); // ???
...
}
}
Personally I find the following much cleaner
public MyResource {
@HttpMethod
public Response post(InputStream data) {
...
return new TemporaryRedirect(somePath);
}
}
I know you want to avoid classes/interfaces but in this case I think
they really simplify things.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.
- application/pkcs7-signature attachment: smime.p7s