rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Geer <ch...@cxtsoftware.com>
Subject Re: REST API & Metadata
Date Wed, 09 Apr 2014 17:29:57 GMT
On Wed, Apr 9, 2014 at 10:23 AM, Matt Franklin <m.ben.franklin@gmail.com>wrote:

> On Wed, Apr 9, 2014 at 10:31 AM, Chris Geer <chris@cxtsoftware.com> wrote:
>
> > On another note, if we are wrapping everything with a
> > JsonResponseWrapper...should we just drop XML support?
> >
>
> I know in the past I have been resistant to dropping XML, but I don't know
> that anyone is using it.
>

I agree but it seems odd to have an object called JsonResponseWrapper being
returned over XML...

>
>
> >
> >
> > On Tue, Apr 8, 2014 at 11:03 PM, Erin Noe-Payne <
> erin.noe.payne@gmail.com
> > >wrote:
> >
> > > The angular branch wraps & unwraps the responses using http
> > > interceptors - it's centrally located so it would be easy to change if
> > > the data format changes.
> > >
> > > On Tue, Apr 8, 2014 at 11:49 PM, Chris Geer <chris@cxtsoftware.com>
> > wrote:
> > > > At some point the new CXF calls all got wrapped with a metadata
> object.
> > > For
> > > > the return types that are lists I understand why we did it but for
> the
> > > > single objects we are returning an empty block. Is there a reason we
> > are
> > > > wrapping the non-list data?
> > > >
> > > > Another thing is, is wrapping the data the right thing to do or
> should
> > we
> > > > be using something like link headers [1] like github does [2][3]?
> > > >
> > > > I could go either way with representing the list data (headers or
> > > metadata)
> > > > but I definitely think we should remove the wrapping for the non-list
> > > data.
> > > > What impact will that have on the Angular branch?
> > > >
> > > > Chris
> > > >
> > > > [1] http://tools.ietf.org/html/rfc5988
> > > > [2] https://developer.github.com/v3/#pagination
> > > > [3]
> > > >
> > >
> >
> http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api#pagination
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message