rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erin Noe-Payne <erin.noe.pa...@gmail.com>
Subject Re: [Proposal] REST API interface
Date Wed, 24 Jul 2013 17:59:15 GMT
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
View raw message