Hi Marcel On Mon, Jun 27, 2011 at 4:25 PM, Marcel Offermans <marcel.offerm...@luminis.eu> wrote: > 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.
Fair enough :) regards, Bram >> > 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. >
