rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Geer <ch...@cxtsoftware.com>
Subject Re: [Proposal] REST API interface
Date Mon, 29 Jul 2013 05:54:38 GMT
On Thu, Jul 25, 2013 at 11:12 AM, Erin Noe-Payne
<erin.noe.payne@gmail.com>wrote:

> I'm not entirely sure how to proceed at the moment. For now I will
> start work at the repository layer and try to implement consistent
> crud operations to support the REST api.
>

Erin, on the CXF 2.7 migration page I saw this.


   - org.apache.cxf.jaxrs.ext.RequestHandler and
   org.apache.cxf.jaxrs.ext.ResponseHandler (use
   javax.ws.rs.container.ContainerRequestFilter and
   javax.ws.rs.container.ContainerResponseFilter instead).


So, it looks like the docs are a little out of date. The
ContainerResponseFilter handler method gets two params, Request Context and
Response Context. That might give you what you need. I haven't played with
it yet but it's worth a look.

Chris



> On Wed, Jul 24, 2013 at 1:59 PM, Erin Noe-Payne
> <erin.noe.payne@gmail.com> wrote:
> > On Wed, Jul 24, 2013 at 1:37 PM, Chris Geer <chris@cxtsoftware.com>
> wrote:
> >> What about this:
> >>
> >>
> http://cxf.apache.org/docs/jax-rs-filters.html#JAX-RSFilters-OverridingrequestURI%2Cqueryandheaders
> >>
> >
> > This is referring to a RequestHandler, not a ResponseHandler. In the
> > request handler the Message object does have correct request uri data,
> > etc, but I don't have access to the Response object yet.
> >
> >> The only thing I don't like about not returning Response objects is it
> >> doesn't let the method set HTTP specific stuff. Which just means we need
> >> really really good filters. For example, a create should set the
> Location
> >> HTTP header field with the proper URL to the newly created object.
> >>
> >
> > That's fair. And the controllers could return response objects and
> > following filters could just iteratively return
> > Response.fromResponse(). But if we take a step back from filters or
> > interceptors or whatever implementation approach, here's the problem
> > I'm trying to solve:
> >
> > Taking your Location header example - all requests to get or create an
> > entity should have the location header set to the canonical url of the
> > resource. Post requests creating a new resource should have a location
> > header pointing to the newly created resource. That is universally
> > true, and I should be able to write that code generically. I do not
> > want to have to set the location header in every controller for every
> > resource that handles the @POST method. That seems like it should be
> > doable, and filters or interceptors seemed like the way to do it. Now
> > I'm not so sure.
> >
> > So is that a goal worth pursuing, and if yes what is the right approach?
> >
> >>
> >> On Wed, Jul 24, 2013 at 9:21 AM, Erin Noe-Payne <
> erin.noe.payne@gmail.com>wrote:
> >>
> >>> Ok, I'm having trouble setting up filters that are able to access
> >>> query string parameters to do pagination. I've submitted a review
> >>> request [1] with my work so far (look at pages, categories, and the
> >>> filters). My plan was the following workflow -
> >>>
> >>> - Request is received and processed by the controller. Controller
> >>> returns an object <T> or List<T> (Page, Category, etc). For
any list
> >>> resource it gets all entities, and allows the pagination filter to
> >>> subset.
> >>> - JsonWrapperResponseFilter process the request and wraps the data
> >>> object in the wrapper object
> >>> - PaginationResponseFilter checks if the data object is a list. It
> >>> retrieves the values of limit and offset QS parameters or sets them to
> >>> defaults. It then subsets the data and sets appropriate meta fields in
> >>> the json object.
> >>>
> >>> The issue is that the response handler does not give me access (as far
> >>> as I can tell) to the query string values. Which makes me think I'm
> >>> missing something, or that this is the wrong way to approach the
> >>> problem.  Any help or input is appreciated.
> >>>
> >>>
> >>> [1] https://reviews.apache.org/r/12901/
> >>>
> >>> On Tue, Jul 23, 2013 at 3:08 PM, Chris Geer <chris@cxtsoftware.com>
> wrote:
> >>> > Good point...I forgot Rave is using CXF 2.7.x which includes that new
> >>> > stuff. That would be a better choice, plus it wouldn't tie us to CXF.
> >>> >
> >>> >
> >>> > On Tue, Jul 23, 2013 at 11:54 AM, Erin Noe-Payne
> >>> > <erin.noe.payne@gmail.com>wrote:
> >>> >
> >>> >> Slight update on this journey of discovery - it looks like what
we
> >>> >> actually want to use is not interceptors, but jaxrs filters. See:
> >>> >> http://cxf.apache.org/docs/jax-rs-filters.html
> >>> >>
> >>> >> On Tue, Jul 23, 2013 at 12:56 PM, Chris Geer <chris@cxtsoftware.com
> >
> >>> >> wrote:
> >>> >> > On Tue, Jul 23, 2013 at 9:55 AM, Erin Noe-Payne <
> >>> >> erin.noe.payne@gmail.com>wrote:
> >>> >> >
> >>> >> >> On Tue, Jul 23, 2013 at 12:14 PM, Chris Geer <
> chris@cxtsoftware.com>
> >>> >> >> wrote:
> >>> >> >> > On Mon, Jul 22, 2013 at 9:04 PM, Erin Noe-Payne <
> >>> >> >> erin.noe.payne@gmail.com>wrote:
> >>> >> >> >
> >>> >> >> >> On Mon, Jul 22, 2013 at 11:56 PM, Chris Geer
<
> >>> chris@cxtsoftware.com>
> >>> >> >> >> wrote:
> >>> >> >> >> > On Mon, Jul 22, 2013 at 12:58 PM, Erin Noe-Payne
> >>> >> >> >> > <erin.noe.payne@gmail.com>wrote:
> >>> >> >> >> >
> >>> >> >> >> >> - Simple solution: All rest response
models are flat. We
> ignore
> >>> >> any
> >>> >> >> >> >> nested data, and just have separate
endpoints to deliver
> that
> >>> >> data.
> >>> >> >> >> >> I.E. Every model in the org.apache.rave.rest.model
package
> has
> >>> >> only
> >>> >> >> >> >> properties of "primitive" types, with
no lists, no other
> >>> classes.
> >>> >> >> That
> >>> >> >> >> >> is NOT currently the case. Then the
fields interceptor
> checks
> >>> for
> >>> >> the
> >>> >> >> >> >> presence of a fields argument. If not
present, the object
> is
> >>> >> >> delivered
> >>> >> >> >> >> as is. If present the argument (a string)
is split by
> comma and
> >>> >> only
> >>> >> >> >> >> the matched properties are delivered.
The fields qs
> argument
> >>> only
> >>> >> has
> >>> >> >> >> >> to support comma-delimited list of property
names.
> >>> >> >> >> >> Ex: ?fields=name,pageType
> >>> >> >> >> >> //returns a page or pages with only
name and pageType
> >>> properties
> >>> >> >> >> >>
> >>> >> >> >> >
> >>> >> >> >> > I like the simple solution. I think the
CRUD part of the API
> >>> should
> >>> >> >> be as
> >>> >> >> >> > flat as possible like Erin suggested and
we have "special"
> end
> >>> >> points
> >>> >> >> to
> >>> >> >> >> > get back hierarchical data when needed,
i.e. page rendering.
> >>> >> >> >> >
> >>> >> >> >>
> >>> >> >> >> Just to make sure we are on the same page, my
proposal is
> that in
> >>> >> both
> >>> >> >> >> cases a get request without any special query
string will
> return
> >>> only
> >>> >> >> >> flat data. The difference is that in the second
case the
> fields
> >>> query
> >>> >> >> >> parameter will support a syntax that CAN deliver
nested data
> in a
> >>> >> >> >> single request.
> >>> >> >> >>
> >>> >> >> >
> >>> >> >> > That confuses me. I thought the whole point of the
"special"
> end
> >>> point
> >>> >> >> was
> >>> >> >> > to handle things like page rendering in one query
which would
> >>> require
> >>> >> >> > hierarchical data every time. Why force the use of
query string
> >>> >> params to
> >>> >> >> > get that?
> >>> >> >> >
> >>> >> >>
> >>> >> >> I was speaking in reference to the standard endpoints.
The
> >>> >> >> page(s)ForRender endpoint is a special endpoint that serves
a
> >>> specific
> >>> >> >> client need for a complex nested data set. It will always
return
> >>> >> >> hierarchical data, will probably not support field selection
at
> all.
> >>> >> >>
> >>> >> >> The standard endpoints will by default return flat data.
They
> will
> >>> >> >> support field selection. If we choose to implement the
more
> complex
> >>> >> >> field selection, then they will allow you to request nested
data
> >>> >> >> through the field selection syntax.
> >>> >> >>
> >>> >> >
> >>> >> > ok
> >>> >> >
> >>> >> >>
> >>> >> >> >>
> >>> >> >> >> >>
> >>> >> >> >> >> - Complicated solution: All rest response
models include
> >>> >> references
> >>> >> >> to
> >>> >> >> >> >> their nested data. This is the currently
the case, and can
> be
> >>> >> seen in
> >>> >> >> >> >> org.apache.rave.rest.model.Page. The
fields interceptor
> checks
> >>> for
> >>> >> >> >> >> presence of fields qs argument. If not
present it strips
> all
> >>> >> nested
> >>> >> >> >> >> data from the models and only returns
properties. If it is
> >>> >> present,
> >>> >> >> it
> >>> >> >> >> >> parses the argument and updates the
data. The fields
> argument
> >>> >> needs
> >>> >> >> to
> >>> >> >> >> >> support a more complicated syntax that
allows the
> requesting of
> >>> >> >> nested
> >>> >> >> >> >> data. I would copy the syntax of facebook's
graph search
> api,
> >>> >> which
> >>> >> >> >> >> has a pretty readable solution. You
allow for .fields and
> >>> .limit
> >>> >> on
> >>> >> >> >> >> fields, which can be nested.
> >>> >> >> >> >> Ex:
> >>> >> >> >> >>
> >>> >> >> >>
> >>> >> >>
> >>> >>
> >>>
> ?fields=name,pageType,regions.limit(2).fields(regionWidgets.fields(widgetId,locked))
> >>> >> >> >> >> //returns a page or pages with name
and pageType
> properties,
> >>> >> nested
> >>> >> >> >> >> list of regions (max of 2) with nested
list of
> regionWidgets
> >>> with
> >>> >> >> only
> >>> >> >> >> >> properties of widgetId and locked
> >>> >> >> >> >>
> >>> >> >> >> >> In all cases, id should always be returned.
> >>> >> >> >> >> I think the algorithm in the simple
solution is easy.
> >>> >> >> >> >> In a sense the algorithm in the second
should be simple,
> >>> because
> >>> >> the
> >>> >> >> >> >> service layer is already getting all
the nested data, and
> you
> >>> are
> >>> >> >> just
> >>> >> >> >> >> stripping it off. Not sure what the
performance
> implications of
> >>> >> that
> >>> >> >> >> >> are though.
> >>> >> >> >> >>
> >>> >> >> >> >> On Mon, Jul 22, 2013 at 3:40 PM, Chris
Geer <
> >>> >> chris@cxtsoftware.com>
> >>> >> >> >> wrote:
> >>> >> >> >> >> > On Mon, Jul 22, 2013 at 12:07 PM,
Erin Noe-Payne
> >>> >> >> >> >> > <erin.noe.payne@gmail.com>wrote:
> >>> >> >> >> >> >
> >>> >> >> >> >> >> Going back to the discussion
on field selection - I am
> >>> >> currently
> >>> >> >> >> going
> >>> >> >> >> >> >> through the exercise of writing
out the Resource
> interfaces
> >>> to
> >>> >> >> define
> >>> >> >> >> >> >> our endpoints.  There is a
set of generic query string
> >>> >> parameters
> >>> >> >> >> that
> >>> >> >> >> >> >> we wish to support on all or
many of the endpoints -
> fields
> >>> >> (any
> >>> >> >> get
> >>> >> >> >> >> >> request), limit / offset (any
get request that returns a
> >>> list).
> >>> >> >> >> >> >>
> >>> >> >> >> >> >> Rather than writing each endpoint
to accept
> QueryParam()'s
> >>> and
> >>> >> >> repeat
> >>> >> >> >> >> >> the appropriate logic, I assume
we would want to take
> >>> >> advantage of
> >>> >> >> >> cxf
> >>> >> >> >> >> >> interceptors [1] to intelligently
and generically handle
> >>> those
> >>> >> qs
> >>> >> >> >> >> >> arguments?
> >>> >> >> >> >> >>
> >>> >> >> >> >> >
> >>> >> >> >> >> > I like the concept but I'm not
sure how we generically
> >>> filter,
> >>> >> >> >> especially
> >>> >> >> >> >> > with nested data. I'd love to see
it work that way
> though.
> >>> >> >> >> Interceptors
> >>> >> >> >> >> are
> >>> >> >> >> >> > pretty easy to use, it's the filter
algorithm I haven't
> >>> figured
> >>> >> out
> >>> >> >> >> yet.
> >>> >> >> >> >> > Thoughts?
> >>> >> >> >> >> >
> >>> >> >> >> >> >>
> >>> >> >> >> >> >> [1] http://cxf.apache.org/docs/interceptors.html
> >>> >> >> >> >> >>
> >>> >> >> >> >> >> On Mon, Jul 22, 2013 at 11:40
AM, Erin Noe-Payne
> >>> >> >> >> >> >> <erin.noe.payne@gmail.com>
wrote:
> >>> >> >> >> >> >> > Ok, so the endpoint is
now working. Any thoughts
> about the
> >>> >> >> >> >> >> > JsonResponseWrapper approach?
Does that seem like the
> best
> >>> >> way
> >>> >> >> to
> >>> >> >> >> get
> >>> >> >> >> >> >> > wrapped responses?
> >>> >> >> >> >> >> >
> >>> >> >> >> >> >> > For the next step I would
like to start writing out
> all of
> >>> >> the
> >>> >> >> >> >> >> > resource interfaces so
that we can begin writing
> angular
> >>> >> >> $resource
> >>> >> >> >> >> >> > services against them.
> >>> >> >> >> >> >> >
> >>> >> >> >> >> >> > On Sun, Jul 21, 2013 at
8:54 PM, Erin Noe-Payne
> >>> >> >> >> >> >> > <erin.noe.payne@gmail.com>
wrote:
> >>> >> >> >> >> >> >> Awesome, thanks Chris.
Not sure I would have ever
> figured
> >>> >> that
> >>> >> >> one
> >>> >> >> >> >> >> out...
> >>> >> >> >> >> >> >>
> >>> >> >> >> >> >> >> On Sun, Jul 21, 2013
at 3:59 PM, Chris Geer <
> >>> >> >> >> chris@cxtsoftware.com>
> >>> >> >> >> >> >> wrote:
> >>> >> >> >> >> >> >>> Erin,
> >>> >> >> >> >> >> >>>
> >>> >> >> >> >> >> >>> I got it working,
at least the CXF part. Couple
> things:
> >>> >> >> >> >> >> >>>
> >>> >> >> >> >> >> >>> 1) In the interface,
make sure to annotate the @GET
> >>> methods
> >>> >> >> >> >> >> >>> 2) In your DefaultRegionWidgetsResource
class,
> remove
> >>> the
> >>> >> >> >> @ParamPath
> >>> >> >> >> >> >> >>> attributes from
variable signatures. I know Intellij
> >>> puts
> >>> >> >> those
> >>> >> >> >> in
> >>> >> >> >> >> >> there
> >>> >> >> >> >> >> >>> but they cause
problems. Only the interface should
> be
> >>> >> >> annotated.
> >>> >> >> >> >> >> >>>
> >>> >> >> >> >> >> >>> Chris
> >>> >> >> >> >> >> >>>
> >>> >> >> >> >> >> >>>
> >>> >> >> >> >> >> >>> On Sat, Jul 20,
2013 at 2:00 PM, Erin Noe-Payne <
> >>> >> >> >> >> >> erin.noe.payne@gmail.com>wrote:
> >>> >> >> >> >> >> >>>
> >>> >> >> >> >> >> >>>> Review board
is not accepting my patch and is not
> >>> >> accepting
> >>> >> >> the
> >>> >> >> >> >> valid
> >>> >> >> >> >> >> >>>> file paths.
I have attached the patch as a file to
> the
> >>> >> >> review.
> >>> >> >> >> >> >> >>>>
> >>> >> >> >> >> >> >>>> On Sat, Jul
20, 2013 at 4:40 PM, Chris Geer <
> >>> >> >> >> chris@cxtsoftware.com
> >>> >> >> >> >> >
> >>> >> >> >> >> >> wrote:
> >>> >> >> >> >> >> >>>> > Erin,
I'm not seeing a patch posted up there.
> >>> >> >> >> >> >> >>>> >
> >>> >> >> >> >> >> >>>> >
> >>> >> >> >> >> >> >>>> > On Fri,
Jul 19, 2013 at 2:27 PM, Erin Noe-Payne <
> >>> >> >> >> >> >> >>>> erin.noe.payne@gmail.com>wrote:
> >>> >> >> >> >> >> >>>> >
> >>> >> >> >> >> >> >>>> >> I
was never able to hit the endpoint as
> expected.
> >>> I've
> >>> >> >> posted
> >>> >> >> >> >> the
> >>> >> >> >> >> >> >>>> >> patch
on the review board if anyone can take a
> look
> >>> and
> >>> >> >> offer
> >>> >> >> >> >> >> advice -
> >>> >> >> >> >> >> >>>> >> https://reviews.apache.org/r/12777/.
> >>> >> >> >> >> >> >>>> >>
> >>> >> >> >> >> >> >>>> >> Thanks
> >>> >> >> >> >> >> >>>> >>
> >>> >> >> >> >> >> >>>> >> On
Fri, Jul 19, 2013 at 2:41 PM, Chris Geer <
> >>> >> >> >> >> chris@cxtsoftware.com
> >>> >> >> >> >> >> >
> >>> >> >> >> >> >> >>>> wrote:
> >>> >> >> >> >> >> >>>> >> >
On Friday, July 19, 2013, Erin Noe-Payne
> wrote:
> >>> >> >> >> >> >> >>>> >> >
> >>> >> >> >> >> >> >>>> >> >>
On Fri, Jul 19, 2013 at 1:24 PM, Chris Geer <
> >>> >> >> >> >> >> chris@cxtsoftware.com
> >>> >> >> >> >> >> >>>> >> <javascript:;>>
> >>> >> >> >> >> >> >>>> >> >>
wrote:
> >>> >> >> >> >> >> >>>> >> >>
> In the xml file you need to create the
> bean,
> >>> then
> >>> >> >> >> reference
> >>> >> >> >> >> >> it in
> >>> >> >> >> >> >> >>>> the
> >>> >> >> >> >> >> >>>> >> >>
> server element near the top. Other than
> >>> that...no,
> >>> >> >> that
> >>> >> >> >> >> >> should be
> >>> >> >> >> >> >> >>>> >> all.
I
> >>> >> >> >> >> >> >>>> >> >>
> assume you set the Path attribute on the
> >>> resource.
> >>> >> >> >> >> >> >>>> >> >>
>
> >>> >> >> >> >> >> >>>> >> >>
I did. I'm also messing around with the
> service
> >>> >> >> injection,
> >>> >> >> >> >> >> which may
> >>> >> >> >> >> >> >>>> >> >>
be the issue. Haven't gotten it to work yet
> >>> though.
> >>> >> >> >> >> >> >>>> >> >>
> >>> >> >> >> >> >> >>>> >> >>
> I thought we were going to do
> >>> >> >> >> >> >> >>>> >> pages/<id>/regions/<id>/regionwidgets/<id>
> >>> >> >> >> >> >> >>>> >> >>
> since it makes no sense to manage a region
> >>> widget
> >>> >> >> >> outside a
> >>> >> >> >> >> >> region
> >>> >> >> >> >> >> >>>> >> >>
outside
> >>> >> >> >> >> >> >>>> >> >>
> a page?
> >>> >> >> >> >> >> >>>> >> >>
 Possibly. Right now I'm just trying to do a
> >>> proof
> >>> >> of
> >>> >> >> >> concept
> >>> >> >> >> >> >> with
> >>> >> >> >> >> >> >>>> the
> >>> >> >> >> >> >> >>>> >> >>
wrapped json object so I picked something
> simple
> >>> >> with
> >>> >> >> the
> >>> >> >> >> >> >> service and
> >>> >> >> >> >> >> >>>> >> >>
rest models already in place.
> >>> >> >> >> >> >> >>>> >> >>
> >>> >> >> >> >> >> >>>> >> >>
In general though I don't see any value to
> >>> dealing
> >>> >> with
> >>> >> >> >> >> region
> >>> >> >> >> >> >> >>>> widgets
> >>> >> >> >> >> >> >>>> >> >>
as a nested resource
> (pages/:id/regions/:id...)
> >>> over
> >>> >> >> just
> >>> >> >> >> >> >> dealing
> >>> >> >> >> >> >> >>>> with
> >>> >> >> >> >> >> >>>> >> >>
them directly. It's just adding weight to the
> >>> pages
> >>> >> >> >> >> controller,
> >>> >> >> >> >> >> >>>> rather
> >>> >> >> >> >> >> >>>> >> >>
than breaking them up and dealing with
> resource
> >>> >> >> concerns
> >>> >> >> >> >> >> separately.
> >>> >> >> >> >> >> >>>> >> >>
> >>> >> >> >> >> >> >>>> >> >>
I get what you're saying about regions and
> >>> >> >> regionwidgets
> >>> >> >> >> only
> >>> >> >> >> >> >> making
> >>> >> >> >> >> >> >>>> >> >>
sense in the context of a page, but you
> could say
> >>> >> the
> >>> >> >> same
> >>> >> >> >> >> >> thing for
> >>> >> >> >> >> >> >>>> >> >>
any 1-many associated resource. Both
> entities are
> >>> >> >> always
> >>> >> >> >> >> >> uniquely
> >>> >> >> >> >> >> >>>> >> >>
identified, so why not deal with them
> >>> individually?
> >>> >> I
> >>> >> >> see
> >>> >> >> >> an
> >>> >> >> >> >> >> upside
> >>> >> >> >> >> >> >>>> of
> >>> >> >> >> >> >> >>>> >> >>
simpler code, consistent api endpoints, and I
> >>> see no
> >>> >> >> >> >> downside.
> >>> >> >> >> >> >> >>>> >> >
> >>> >> >> >> >> >> >>>> >> >
> >>> >> >> >> >> >> >>>> >> >
Honestly, my hope is that someday they aren't
> >>> >> uniquely
> >>> >> >> >> >> >> identified and
> >>> >> >> >> >> >> >>>> are
> >>> >> >> >> >> >> >>>> >> >
really sun objects unlike JPA today. But that
> is a
> >>> >> >> longer
> >>> >> >> >> >> >> >>>> conversation.
> >>> >> >> >> >> >> >>>> >> >
> >>> >> >> >> >> >> >>>> >> >>
> >>> >> >> >> >> >> >>>> >> >>
>
> >>> >> >> >> >> >> >>>> >> >>
>
> >>> >> >> >> >> >> >>>> >> >>
> On Fri, Jul 19, 2013 at 10:16 AM, Erin
> >>> Noe-Payne
> >>> >> >> >> >> >> >>>> >> >>
> <erin.noe.payne@gmail.com>wrote:
> >>> >> >> >> >> >> >>>> >> >>
>
> >>> >> >> >> >> >> >>>> >> >>
>> I'm trying to register a new endpoint for
> >>> >> >> >> regionWidgets.
> >>> >> >> >> >> I've
> >>> >> >> >> >> >> >>>> added
> >>> >> >> >> >> >> >>>> >> >>
>> the interface and default implementation,
> and
> >>> >> >> created /
> >>> >> >> >> >> >> registered
> >>> >> >> >> >> >> >>>> >> the
> >>> >> >> >> >> >> >>>> >> >>
>> bean in cxf-applicationContext.xml.
> >>> >> >> >> >> >> >>>> >> >>
>>
> >>> >> >> >> >> >> >>>> >> >>
>> However, when I hit the endpoint I get an
> >>> error:
> >>> >> >> >> >> >> >>>> >> >>
>> [INFO] [talledLocalContainer] WARN :
> >>> >> >> >> >> >> >>>> >> >>
>> org.apache.cxf.jaxrs.utils.JAXRSUtils - No
> >>> >> operation
> >>> >> >> >> >> matching
> >>> >> >> >> >> >> >>>> request
> >>> >> >> >> >> >> >>>> >> >>
>> path "/portal/api/rest/regionWidgets/1" is
> >>> found,
> >>> >> >> >> Relative
> >>> >> >> >> >> >> Path:
> >>> >> >> >> >> >> >>>> /1,
> >>> >> >> >> >> >> >>>> >> >>
>> HTTP Method: GET, ContentType: */*,
> Accept:
> >>> >> >> >> >> >> >>>> >> >>
>>
> >>> >> >> >> >> >>
> >>> >> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,.
> >>> >> >> >> >> >> >>>> >> >>
>> Please enable FINE/TRACE log level for
> more
> >>> >> details.
> >>> >> >> >> >> >> >>>> >> >>
>>
> >>> >> >> >> >> >> >>>> >> >>
>> Is there anything else I need to do in
> order
> >>> to
> >>> >> >> create
> >>> >> >> >> and
> >>> >> >> >> >> >> >>>> register a
> >>> >> >> >> >> >> >>>> >> >>
>> new endpoint?
> >>> >> >> >> >> >> >>>> >> >>
>>
> >>> >> >> >> >> >> >>>> >> >>
>> On Tue, Jul 16, 2013 at 11:53 PM, Erin
> >>> Noe-Payne
> >>> >> >> >> >> >> >>>> >> >>
>> <erin.noe.payne@gmail.com> wrote:
> >>> >> >> >> >> >> >>>> >> >>
>> > On Tue, Jul 16, 2013 at 10:24 PM, Chris
> >>> Geer <
> >>> >> >> >> >> >> >>>> >> chris@cxtsoftware.com>
> >>> >> >> >> >> >> >>>> >> >>
>> wrote:
> >>> >> >> >> >> >> >>>> >> >>
>> >> On Tue, Jul 16, 2013 at 7:04 PM, Erin
> >>> >> Noe-Payne <
> >>> >> >> >> >> >> >>>> >> >>
>> erin.noe.payne@gmail.com>wrote:
> >>> >> >> >> >> >> >>>> >> >>
>> >>
> >>> >> >> >> >> >> >>>> >> >>
>> >>> On Tue, Jul 16, 2013 at 9:20 PM, Matt
> >>> >> Franklin <
> >>> >> >> >> >> >> >>>> >> >>
>> m.ben.franklin@gmail.com>
> >>> >> >> >> >> >> >>>> >> >>
>> >>> wrote:
> >>> >> >> >> >> >> >>>> >> >>
>> >>> > On Tue, Jul 16, 2013 at 12:53 PM,
> Chris
> >>> >> Geer <
> >>> >> >> >> >> >> >>>> >> >>
chris@cxtsoftware.com>
> >>> >> >> >> >> >> >>>> >> >>
>> >>> wrote:
> >>> >> >> >> >> >> >>>> >> >>
>> >>> >
> >>> >> >> >> >> >> >>>> >> >>
>> >>> >> On Tue, Jul 16, 2013 at 10:32 AM,
> Erin
> >>> >> >> Noe-Payne
> >>> >> >> >> >> >> >>>> >> >>
>> >>> >> <erin.noe.payne@gmail.com>wrote:
> >>> >> >> >> >> >> >>>> >> >>
>> >>> >>
> >>> >> >> >> >> >> >>>> >> >>
>> >>> >> > Any further discussion here? I
> would
> >>> >> like
> >>> >> >> to
> >>> >> >> >> >> start
> >>> >> >> >> >> >> >>>> >> implementing
> >>> >> >> >> >> >> >>>> >> >>
>> more
> >>> >> >> >> >> >> >>>> >> >>
>> >>> >> > of the REST APIs, as it is
> >>> foundational
> >>> >> for
> >>> >> >> >> the
> >>> >> >> >> >> >> entire
> >>> >> >> >> >> >> >>>> >> angular
> >>> >> >> >> >> >> >>>> >> >>
>> >>> >> > architecture.
> >>> >> >> >> >> >> >>>> >> >>
>> >>> >> >
> >>> >> >> >> >> >> >>>> >> >>
>> >>> >> > My understanding from Matt is
> that
> >>> the
> >>> >> >> current
> >>> >> >> >> >> apis
> >>> >> >> >> >> >> in
> >>> >> >> >> >> >> >>>> trunk
> >>> >> >> >> >> >> >>>> >> >>
are
> >>> >> >> >> >> >> >>>> >> >>
>> >>> >> > mostly proof of concept - they
> are
> >>> not
> >>> >> >> tested
> >>> >> >> >> and
> >>> >> >> >> >> >> much of
> >>> >> >> >> >> >> >>>> >> the
> >>> >> >> >> >> >> >>>> >> >>
>> >>> >> > functionality is just stubbed.
> Are
> >>> any
> >>> >> of
> >>> >> >> the
> >>> >> >> >> >> rest
> >>> >> >> >> >> >> api
> >>> >> >> >> >> >> >>>> >> >>
>> implementations
> >>> >> >> >> >> >> >>>> >> >>
>> >>> >> > in the code base a good working
> >>> >> example? Is
> >>> >> >> >> there
> >>> >> >> >> >> >> other
> >>> >> >> >> >> >> >>>> >> >>
>> documentation
> >>> >> >> >> >> >> >>>> >> >>
>> >>> >> > we can reference?
> >>> >> >> >> >> >> >>>> >> >>
>> >>> >> >
> >>> >> >> >> >> >> >>>> >> >>
>> >>> >>
> >>> >> >> >> >> >> >>>> >> >>
>> >>> >> I've been working on the People
> >>> resource
> >>> >> as a
> >>> >> >> >> >> >> "reference"
> >>> >> >> >> >> >> >>>> of
> >>> >> >> >> >> >> >>>> >> how
> >>> >> >> >> >> >> >>>> >> >>
I'd
> >>> >> >> >> >> >> >>>> >> >>
>> >>> like
> >>> >> >> >> >> >> >>>> >> >>
>> >>> >> to see them done but it's still a
> work
> >>> in
> >>> >> >> >> >> progress. I
> >>> >> >> >> >> >> need
> >>> >> >> >> >> >> >>>> to
> >>> >> >> >> >> >> >>>> >> go
> >>> >> >> >> >> >> >>>> >> >>
>> back
> >>> >> >> >> >> >> >>>> >> >>
>> >>> and
> >>> >> >> >> >> >> >>>> >> >>
>> >>> >> pull out the JSONView stuff and
> >>> >> reimplement
> >>> >> >> the
> >>> >> >> >> >> >> "fields"
> >>> >> >> >> >> >> >>>> >> concept.
> >>> >> >> >> >> >> >>>> >> >>
>> >>> Couple of
> >>> >> >> >> >> >> >>>> >> >>
>> >>> >> notes:
> >>> >> >> >> >> >> >>>> >> >>
>> >>> >>
> >>> >> >> >> >> >> >>>> >> >>
>> >>> >>  - Object representations should
> be as
> >>> >> flat
> >>> >> >> as
> >>> >> >> >> >> >> possible
> >>> >> >> >> >> >> >>>> >> >>
>> >>> >> and separate requests should be
> made to
> >>> >> >> nested
> >>> >> >> >> >> >> resources to
> >>> >> >> >> >> >> >>>> >> get
> >>> >> >> >> >> >> >>>> >> >>
>> nested
> >>> >> >> >> >> >> >>>> >> >>
>> >>> >> details (i.e. if you have regions
> and
> >>> >> >> >> >> >> >>>> regions/1/regionwidgets,
> >>> >> >> >> >> >> >>>> >> >>
the
> >>> >> >> >> >> >> >>>> >> >>
>> >>> regions
> >>> >> >> >> >> >> >>>> >> >>
>> >>> >> representation should not contain
> an
> >>> >> array of
> >>> >> >> >> >> >> >>>> regionwidgets)
> >>> >> >> >> >> >> >>>> >> >>
>> >>> >>
> >>> >> >> >> >> >> >>>> >> >>
>> >>> >
> >>> >> >> >> >> >> >>>> >> >>
>> >>> > I am concerned about the round
> trips to
> >>> >> >> support
> >>> >> >> >> this
> >>> >> >> >> >> >> when
> >>> >> >> >> >> >> >>>> >> >>
rendering
> >>> >> >> >> >> >> >>>> >> >>
>> the
> >>> >> >> >> >> >> >>>> >> >>
>> >>> > page.  With any page that has a
> >>> sufficient
> >>> >> >> >> number of
> >>> >> >> >> >> >> >>>> gadgets,
> >>> >> >> >> >> >> >>>> >> >>
adding
> >>> >> >> >> >> >> >>>> >> >>
>> to
> >>> >> >> >> >> >> >>>> >> >>
>> >>> the
> >>> >> >> >> >> >> >>>> >> >>
>> >>> > number of requests becomes
> problematic.
> >>> >> >> >> >> >> >>>> >> >>
>> >>> >
> >>> >> >> >> >> >> >>>> >> >>
>> >>>
> >>> >> >> >> >> >> >>>> >> >>
>> >>> I see that rule applying to the
> "standard"
> >>> >> rest
> >>> >> >> >> >> >> endpoints for
> >>> >> >> >> >> >> >>>> >> crud
> >>> >> >> >> >> >> >>>> >> >>
>> >>> operations on resources. We
> >>> >> >> >> >> >> >>>> >>
> >>> >> >> >> >> >> >>>>
> >>> >> >> >> >> >>
> >>> >> >> >> >>
> >>> >> >> >>
> >>> >> >>
> >>> >>
> >>>
>

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