adding json rest handling to AbstractCollectionAdapter

[David Primmer <da...@gmail.com>]

I'm looking for a way to split off processing in the collection
adapter into json input and output processing (without going through a
translation into the FOM). The two areas I'm looking at are
AbstractCollectionAdapter and AbstractEntityCollectionAdapter. The
reality of my implementation is that the json objects in the request
body are basically the same as the pojo's that are the storage
interface, so why go through the abstraction of the FOM?

I'm trying to add json to backend java objects to the request/response
processing pipeline of Abdera but do I need to change abdera to do it?
I've noticed there are separate processing systems for media handling
and xml handling. The various build* methods, like
AbstractCollectionAdapter.buildCreateEntryResponse, that creates
ResponseContext for the entry object and sets up the common
http-oriented elements of the response. Seems re-usable for a generic
json REST server. Seems like I could extend the
AbstractCollectionAdapter.

Is it true that to keep this simpler, I'd want to keep the Feed and
Entry interfaces? So a json 'entry' or a json 'feed' could be used
with stuff like getEntryFromRequest. But not use any of the RFC4287
stuff in the Source class? getEntryFromRequest retrieves the Entry
object from the request payload. It creates a parser object which
could be replaced with a json parser.

What about using some of the stuff in AbstractEntityCollectionAdapter?
It seems very tied to XML. Would ProvidorHelper.isValidEntry need to
be extended to support json also? Is this just a very slippery slope
that is not worth getting on?

thanks!

davep

Re: adding json rest handling to AbstractCollectionAdapter

[James M Snell <ja...@gmail.com>]

Sorry for getting back to this so late. Comments below...

David Primmer wrote:
> I'm looking for a way to split off processing in the collection
> adapter into json input and output processing (without going through a
> translation into the FOM). The two areas I'm looking at are
> AbstractCollectionAdapter and AbstractEntityCollectionAdapter. The
> reality of my implementation is that the json objects in the request
> body are basically the same as the pojo's that are the storage
> interface, so why go through the abstraction of the FOM?
> 

There are several ways to handle this.  In one of my implementations, 
I've created a custom ResponseContext that uses the JSON writer to 
serialize output directly from the source objects.  No FOM necessary.

> I'm trying to add json to backend java objects to the request/response
> processing pipeline of Abdera but do I need to change abdera to do it?
> I've noticed there are separate processing systems for media handling
> and xml handling. The various build* methods, like
> AbstractCollectionAdapter.buildCreateEntryResponse, that creates
> ResponseContext for the entry object and sets up the common
> http-oriented elements of the response. Seems re-usable for a generic
> json REST server. Seems like I could extend the
> AbstractCollectionAdapter.
> 
> Is it true that to keep this simpler, I'd want to keep the Feed and
> Entry interfaces? So a json 'entry' or a json 'feed' could be used
> with stuff like getEntryFromRequest. But not use any of the RFC4287
> stuff in the Source class? getEntryFromRequest retrieves the Entry
> object from the request payload. It creates a parser object which
> could be replaced with a json parser.
> 

There shouldn't be any need at all for implementing the Feed and Entry 
interfaces.  Just go directly from your application objects to JSON 
using a custom ResponseContext implementation.

> What about using some of the stuff in AbstractEntityCollectionAdapter?
> It seems very tied to XML. Would ProvidorHelper.isValidEntry need to
> be extended to support json also? Is this just a very slippery slope
> that is not worth getting on?
> 

I think it would be easier to either extend AbstractCollectionAdapter or 
just implement CollectionAdapter directly. 
AbstractEntityCollectionAdapter seems a bit too specific for your case.

- James

> thanks!
> 
> davep
>