Hello Bram, > I like the revised proposal on the wiki. Below just two minor comments > in response to yours.
Responses inline below... > What I am wondering about is how you will implement this. The current > ACE approach seems a basic servlet that directly hooks into the http > service whiteboard. In Amdatu we also provide a Wink based bridge that > allows you to simply publish a JAX-RS annotated service. Either way, > from an Amdatu standpoint, we need a way to integrate such a component > into the muilti-tenant model. So probably more a discussion for the > Amdatu list, but just curious how you plan to implement this in ACE :) It makes sense, from an ACE point of view, to stick to the basic servlet model. ACE has a multi-tenancy model, but it's different from the Amdatu model, and I think it makes more sense to discuss that on the Amdatu list. I will follow up there. > > My idea was that this could just as well be a relative URL (just > > like you can have those in an HTML page), but maybe in this case > > (the POST request that creates something new) it makes sense to > > return a full URL (when GETting long lists of items, relative URLs > > sound a lot more appealing to me). > > HTTP spec wise the location header must be absolute (although most > browsers will happily accept relative as well). From a HATEOAS > standpoint I think it's a preference thing. Keeping URI construction > on the server make stuff more robust and flexible. On the other hand > you'll have to account for infrastructure that has to rewrite etc. An > alternative approach is adding an xml:base construct to the > representation. Anyway, in the end I think for the ACE use case it > does not make much difference. I'm not advocating we should start sending HTTP requests with relative URLs. I just want to avoid them in the response, where we can just assume that any URL is relative to the original request (or whatever you got redirected to). > > I'm not sure if we want to make the way we map our entities to > > XML part of the public API. I'll take a look at gson, but can you > > explain why you would use it here over the many other json libraries > > out there? > > To be honest I cannot really compare. I've used gson many times. It's > flexible, lightweight, optimized pretty well and has no dependencies. > Other then that there may be many framework providing the same or > more. Fair enough, gson looks interesting, so I'll use it for this component.
