Paul,
> I think this is an improvement over your previous thoughts on having:
>
> @CreationRef
> public String getIdentifier() {...}
>
> which IMHO introduces much more complexity than annotating
> the HTTP method.
Hopefully the thread that I've just started will explain why I think both
approaches are useful and complimentary to adapt to various POJO designs.
> The idea of using a URI template is a nice touch. Also I also find
> rather appealing the renaming of UriTemplate and HttpMethod to
> WebResource (i consider the issue with the WebResource interface as
> separate thing) and WebMethod respectively.
>
> > Of course, if finer control is preferred, we could have:
> >
> > @WebResource("/orders/{orderId}")
> > public Order {
> >
> > @WebMethod
> > public void post(InputStream data) {
> > ...
> >
> > @Resource
> > Context ctx;
>
> 'ctx' would need to be a field on the class or a parameter of
> the method for standard injection to work. (we could do some byte code
injection :-) but that is tricky!)
OK, using a field is fine I guess.
> > ctx.redirectPermanent("/target/{orderId}";
> > }
> > }
>
> How are the two approaches above simpler than having just one
> solution to solve the problem, namely the returning of a Java object
> (as Marc has previously shown):
>
> return new PermanentRedirect("/target/{orderId}");
Because with one Context class you can solve many other problems like
setting the status code, the reason phrase, local forward. It's simpler than
having to rely on:
- HttpContext
- HttpRequestContext
- HttpResponseContext
- WebResource
- Created
- HttpResponse
- NotModified
- TemporaryRedirect
1 class instead of 8 different types, without loosing features is compelling
enough for me.
Best regards,
Jerome