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 16:21:22 GMT
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