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 Fri, 19 Jul 2013 18:41:39 GMT
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