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 Sun, 21 Jul 2013 19:59:05 GMT
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