ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bram de Kruijff <bdekrui...@gmail.com>
Subject Re: [jira] [Created] (ACE-151) Create a REST client API
Date Tue, 28 Jun 2011 09:47:57 GMT
Hi Marcel

On Mon, Jun 27, 2011 at 4:25 PM, Marcel Offermans
<marcel.offermans@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.
>

Mime
View raw message