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 Thu, 25 Jul 2013 18:12:39 GMT
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.

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
View raw message