[Apiman-user] REST Sample
Eric Wittmann
eric.wittmann at redhat.com
Thu Jul 23 07:27:36 EDT 2015
It's true that in some places the response payload includes more
information than is necessary given the context. That is largely due to
the fact that the same information can be returned from multiple URLs,
as Jakub noted. So asking for all services in an Org returns the same
info as if you search for services. In the latter case the org info is
needed.
@Jakub - Regarding IDs I think that's a very good/valid point. I've
added a feature request to JIRA to include URIs in the response payloads.
https://issues.jboss.org/browse/APIMAN-565
-Eric
On 7/23/2015 4:40 AM, Jakub Čecháček wrote:
>> I think a cleaner payload would be: ...
>
> Unless I overlooked something the two example payloads are identical.
> Regardless I agree that current JSON responses could be improved.
>
> However in this particular case I am not sure whether "duplicities" are
> an issue. The requested resources (services) just happened to have the
> same parent. Also extracting these duplicities would mean that resources
> listed under .../services and /services/{id} would be different, which
> doesn't make sense as the former is just a list of all services
> available after providing {id} as part of the url.
>
> For my point of view a possible issue is the use of "id" attributes --
> such attributes lack semantics and resource urls should be used instead
> (as it allows transition between resources) [1]. Nevertheless there is
> a plenty of APIs which are using ID attributes so I would consider this
> to be of minor importance.
>
> > When an organization is created, seems like organizationId is derived
> from organizationName? What's the purpose of two fields uniquely
> identifying an organization?
>
> As you said, id is derived not copied -- some characters (such as
> whitespace) are removed or replaced, thus the value of both fields can
> be different. Name is meant for human users to read, id as a system
> identifier.
>
>>Can id, name, description attributes for service be renamed to
> serviceId, serviceName, serviceDescription?
>
> The requested resource is list of all services. I would kinda assume
> that all attributes (unless something indicates otherwise) are
> attributes of service object. So what would be the point of making the
> attribute names more complicated? Again changing the attributes here
> would require to mirror these changes to .../services/{id}
>
> [1] Interesting presentation about REST api design. Unfortunately author
> mixed in some Czech for no reason. The important stuff is in English
> though. https://speakerdeck.com/honzajavorek/rest-api-manual
>
> Jakub.
>
> On Thu, Jul 23, 2015 at 12:49 AM, Arun Gupta <arun.gupta at gmail.com
> <mailto:arun.gupta at gmail.com>> wrote:
>
> Moving to swagger will be good!
>
> Can reasonable defaults be assumed? For example, not setting
> endpointType currently sets it to null. It'll be convenient if it is
> assumed it to be "rest". That is going to be the most common use case
> anyway. How does the processing differ if the endpointType is set to
> "soap"?
>
> Another question ...
>
> Accessing the list of services for an organization as:
>
> curl --user admin:admin123! -H "Accept: application/json"
> http://192.168.99.103:8082/apiman/organizations/everest/services
>
> And the generated payload is:
>
> [{"organizationId":"everest","organizationName":"everest","id":"catalog","name":"catalog","description":"catalog
> service","createdOn":1437575090081},{"organizationId":"everest","organizationName":"everest","id":"order","name":"order","description":"order
> service","createdOn":1437575867804},{"organizationId":"everest","organizationName":"everest","id":"user","name":"user","description":"user
> service","createdOn":1437575649446}]
>
> A few issues with this ...
>
> - Why organizationId and organizationName are repeated with each
> service? I think a cleaner payload would be:
>
> [{"organizationId":"everest","organizationName":"everest","id":"catalog","name":"catalog","description":"catalog
> service","createdOn":1437575090081},{"organizationId":"everest","organizationName":"everest","id":"order","name":"order","description":"order
> service","createdOn":1437575867804},{"organizationId":"everest","organizationName":"everest","id":"user","name":"user","description":"user
> service","createdOn":1437575649446}]
>
> - When an organization is created, seems like organizationId is
> derived from organizationName? What's the purpose of two fields
> uniquely identifying an organization?
>
> - Can id, name, description attributes for service be renamed to
> serviceId, serviceName, serviceDescription?
>
> Thanks,
> Arun
>
> On Wed, Jul 22, 2015 at 10:17 AM, Eric Wittmann
> <eric.wittmann at redhat.com <mailto:eric.wittmann at redhat.com>> wrote:
> > Fair questions all.
> >
> > - Everything is optional in the payload so that you can set
> individual
> > properties without sending *everything*
> > - Only the 'gateways' has a default value - but it will default
> only if
> > there is a single gateway installed in apiman. if multiple
> gateways have
> > been configured, then you must pick one
> >
> > We'll likely be moving the API documentation over to swagger at
> some point,
> > replacing the miredot docs.
> >
> > -Eric
> >
> > On 7/22/2015 9:02 AM, Arun Gupta wrote:
> >>
> >> Here is the inbound payload for
> >>
> >>
> http://localhost:8080/apiman/organizations/organizationId/services/serviceId/versions/version:
> >>
> >> {
> >> endpointType:rest | soap
> >> publicService:boolean
> >> endpointProperties:{
> >> string =>string
> >> }
> >> gateways:[
> >> {
> >> gatewayId:string
> >> }
> >> ]
> >> plans:[
> >> {
> >> version:string
> >> planId:string
> >> }
> >> ]
> >> endpoint:string
> >> }
> >>
> >> How do I know which parts of optional? Why "gateways" is an array of
> >> objects instead of array of string?
> >>
> >> Can there be defaults assumed if nothing is specified in the
> payload?
> >> For example, make the service public by default, use rest type,
> assign
> >> no plan, and have no endpoint properties.
> >>
> >> Created https://issues.jboss.org/browse/APIMAN-559 for syntax
> highlighter.
> >>
> >> Arun
> >>
> >> On Wed, Jul 22, 2015 at 8:33 AM, Eric Wittmann
> <eric.wittmann at redhat.com <mailto:eric.wittmann at redhat.com>>
> >> wrote:
> >>>
> >>> There is a feature request already in JIRA for allowing the
> POST (create
> >>> new
> >>> service version) to include all of the same information that a
> PUT would
> >>> allow. A future version will allow this.
> >>>
> >>> https://issues.jboss.org/browse/APIMAN-427
> >>>
> >>> Which optional parts are not indicated?
> >>>
> >>> -Eric
> >>>
> >>> On 7/21/2015 10:19 PM, Arun Gupta wrote:
> >>>>
> >>>>
> >>>> POST on
> >>>>
> >>>>
> http://localhost:8080/apiman/organizations/{organizationId}/services/{serviceId}/versions
> >>>> takes only:
> >>>>
> >>>> {
> >>>> version:string
> >>>> cloneVersion:string
> >>>> clone:boolean
> >>>> }
> >>>>
> >>>> and returns all the information about the created endpoint,
> including
> >>>> all the information that needs to be set later by calling PUT on
> >>>>
> >>>>
> >>>>
> http://localhost:8080/apiman/organizations/{organizationId}/services/{serviceId}/versions/{versionId}.
> >>>>
> >>>> Was there discussion about taking in the relevant information
> as part
> >>>> of original POST request?
> >>>>
> >>>> Also, optional JSON parts are not indicated in the payload.
> How can
> >>>> that be done?
> >>>>
> >>>> Can an appropriate syntax highlighter be used?
> >>>>
> >>>> Arun
> >>>>
> >>>> On Tue, Jul 21, 2015 at 6:11 PM, Eric Wittmann
> >>>> <eric.wittmann at redhat.com <mailto:eric.wittmann at redhat.com>>
> >>>> wrote:
> >>>>>
> >>>>>
> >>>>> It depends on a number of variables. But basically for each
> service
> >>>>> you
> >>>>> want to create you'll need at least:
> >>>>>
> >>>>> 1) create the service
> >>>>> 2) create version of the service
> >>>>> 3) update version with the desired settings (endpoint info,
> plans, etc)
> >>>>> 4) publish version (pushes it to the gateway)
> >>>>>
> >>>>> That would be for a public service with no policies.
> >>>>>
> >>>>> If you want to configure it with policies, then there are
> extra calls
> >>>>> for
> >>>>> that. If you wanted to add a service definition (swagger)
> then there's
> >>>>> a
> >>>>> separate call for that. Etc.
> >>>>>
> >>>>> You'll of course need an organization to hold the services.
> You also
> >>>>> need
> >>>>> to create and lock plans if you intend to use multiple
> plans. If you
> >>>>> use
> >>>>> plans (vs. public services) you'll need to create
> applications and then
> >>>>> contracts between the apps and the service(s). :)
> >>>>>
> >>>>> -Eric
> >>>>>
> >>>>> On 7/21/2015 5:06 PM, Arun Gupta wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> This is helpful!
> >>>>>>
> >>>>>> What is the minimum number of calls required for registering
> endpoints
> >>>>>> for a few services?
> >>>>>>
> >>>>>> Arun
> >>>>>>
> >>>>>> On Tue, Jul 21, 2015 at 7:11 AM, Eric Wittmann
> >>>>>> <eric.wittmann at redhat.com <mailto:eric.wittmann at redhat.com>>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> There is a test plan in apiman that does all of this. It
> can be
> >>>>>>> found
> >>>>>>> here:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> https://github.com/apiman/apiman/blob/master/test/suite/src/main/resources/scripts/api-manager-testPlan.xml
> >>>>>>>
> >>>>>>> Each of the tests in the XML file is executed in order,
> starting with
> >>>>>>> this
> >>>>>>> one:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> https://github.com/apiman/apiman/blob/master/test/suite/src/main/resources/data/orgs/001_create-test.resttest
> >>>>>>>
> >>>>>>> The format of each *.resttest file is:
> >>>>>>>
> >>>>>>> VERB /path/to/API/resource user/pass
> >>>>>>> Request-Header-1: value
> >>>>>>> Request-Header-2: value
> >>>>>>>
> >>>>>>> {
> >>>>>>> "json" : "payload"
> >>>>>>> }
> >>>>>>> ----
> >>>>>>> expectedResponseCode
> >>>>>>> Expected-Response-Header-1: value
> >>>>>>> Expected-Response-Header-2: value
> >>>>>>>
> >>>>>>> {
> >>>>>>> "expected-json" : "response-payload"
> >>>>>>> }
> >>>>>>>
> >>>>>>> So basically you would be interested only in what is above
> the "----"
> >>>>>>> separator.
> >>>>>>>
> >>>>>>> You are right - we should write a blog post or document a
> hello world
> >>>>>>> use-case.
> >>>>>>>
> >>>>>>> -Eric
> >>>>>>>
> >>>>>>>
> >>>>>>> On 7/20/2015 7:11 PM, Arun Gupta wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Is there a sample that shows the complete creation/order of
> >>>>>>>> organization, services, endpoints, etc using the REST API?
> >>>>>>>>
> >>>>>>>> The documents at [1] are helpful but a Hello World sample
> would be
> >>>>>>>> very useful. I started creating a sample at [2].
> >>>>>>>>
> >>>>>>>> [1] http://www.apiman.io/latest/api-manager-restdocs.html
> >>>>>>>> [2]
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> https://github.com/arun-gupta/microservices/blob/master/microservice/docker/Dockerfile
> >>>>>>>>
> >>>>>>>> Cheers,
> >>>>>>>> Arun
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >>
> >
>
>
>
> --
> http://blog.arungupta.me
> http://twitter.com/arungupta
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
More information about the Apiman-user
mailing list