ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <>
Subject RE: [jira] [Created] (ACE-151) Create a REST client API
Date Mon, 27 Jun 2011 14:25:06 GMT
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.

View raw message