From eric.wittmann at redhat.com Mon Jul 6 12:57:11 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Mon, 06 Jul 2015 12:57:11 -0400 Subject: [Apiman-user] Announcement: apiman 1.1.4.Final Message-ID: <559AB367.1050104@redhat.com> Hey everyone! I'm happy to announce that we just released apiman version 1.1.4.Final! This release has a number of bugs fixed, of course. But most interestingly we finally have some reasonable metrics! There is a new UI tab on the Service Details page labeled "Metrics" (not very original, but accurate!). This tab only shows up for published services (those that could potentially have metrics data). Clicking it will show a number of metrics graphs integrated right into the apiman UI. Don't worry - full details will be documented and blogged about! http://www.apiman.io/latest/ Enjoy and let us know if you find any problem. Also if you are interested in metrics, let us know what *other* metrics graphs you would want to see in the UI. -Eric From 00hf11 at gmail.com Mon Jul 6 16:39:35 2015 From: 00hf11 at gmail.com (Helio Frota) Date: Mon, 6 Jul 2015 17:39:35 -0300 Subject: [Apiman-user] Announcement: apiman 1.1.4.Final In-Reply-To: <559AB367.1050104@redhat.com> References: <559AB367.1050104@redhat.com> Message-ID: Awesome ! +1 On Mon, Jul 6, 2015 at 1:57 PM, Eric Wittmann wrote: > Hey everyone! > > I'm happy to announce that we just released apiman version 1.1.4.Final! > > This release has a number of bugs fixed, of course. But most > interestingly we finally have some reasonable metrics! There is a new > UI tab on the Service Details page labeled "Metrics" (not very original, > but accurate!). This tab only shows up for published services (those > that could potentially have metrics data). Clicking it will show a > number of metrics graphs integrated right into the apiman UI. > > Don't worry - full details will be documented and blogged about! > > http://www.apiman.io/latest/ > > Enjoy and let us know if you find any problem. Also if you are > interested in metrics, let us know what *other* metrics graphs you would > want to see in the UI. > > -Eric > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20150706/9519e948/attachment.html From ldimaggi at redhat.com Mon Jul 6 23:09:25 2015 From: ldimaggi at redhat.com (Len DiMaggio) Date: Mon, 6 Jul 2015 23:09:25 -0400 (EDT) Subject: [Apiman-user] Announcement: apiman 1.1.4.Final In-Reply-To: <559AB367.1050104@redhat.com> References: <559AB367.1050104@redhat.com> Message-ID: <1705366204.15072339.1436238565456.JavaMail.zimbra@redhat.com> Congrats to the apiman team! ----- Original Message ----- | From: "Eric Wittmann" | To: apiman-user at lists.jboss.org | Sent: Monday, July 6, 2015 12:57:11 PM | Subject: [Apiman-user] Announcement: apiman 1.1.4.Final | Hey everyone! | I'm happy to announce that we just released apiman version 1.1.4.Final! | This release has a number of bugs fixed, of course. But most | interestingly we finally have some reasonable metrics! There is a new | UI tab on the Service Details page labeled "Metrics" (not very original, | but accurate!). This tab only shows up for published services (those | that could potentially have metrics data). Clicking it will show a | number of metrics graphs integrated right into the apiman UI. | Don't worry - full details will be documented and blogged about! | http://www.apiman.io/latest/ | Enjoy and let us know if you find any problem. Also if you are | interested in metrics, let us know what *other* metrics graphs you would | want to see in the UI. | -Eric | _______________________________________________ | Apiman-user mailing list | Apiman-user at lists.jboss.org | https://lists.jboss.org/mailman/listinfo/apiman-user -- Len DiMaggio (ldimaggi at redhat.com) JBoss by Red Hat 314 Littleton Road Westford, MA 01886 USA tel: 978.392.3179 cell: 781.472.9912 http://www.redhat.com http://community.jboss.org/people/ldimaggio -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20150706/29ea44f1/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: RHxJBpngthumb.png Type: image/png Size: 9435 bytes Desc: not available Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20150706/29ea44f1/attachment.png From cmoulliard at redhat.com Wed Jul 8 13:44:47 2015 From: cmoulliard at redhat.com (Charles Moulliard) Date: Wed, 8 Jul 2015 19:44:47 +0200 Subject: [Apiman-user] Mapping between REST services (GET/POST/PT/DELETE) & API Gateway Message-ID: <559D618F.5010706@redhat.com> Hi, The API Manager allows to map the proxy service (= service to be authorized) with the real service exposed by example by a REST Endpoint If the REST service exposes GET, PUT, DELETE & POST methods that we ca nreach using these curl requests : 1) GET curl http://localhost:8080/cxf/rest/customerservice/customers/123 2) POST curl -i -H "Content-Type: application/json" -X POST -d '{"Customer":{"name":"Charles"}}' http://localhost:8080/cxf/rest/customerservice/customers 3) PUT curl -i -H "Content-Type: application/json" -X PUT -d '{"Customer":{"id":124,"name":"TUG"}}' http://localhost:8080/cxf/rest/customerservice/customers 4) Delete curl -X DEL http://localhost:8080/cxf/rest/customerservice/customers/124 I have encoded this service API : http://localhost:9090/rest/customerservice/customers/ but when I try to reach it using the proxy API ("curl -v -k -H "Authorization: Bearer $TOKEN" https://127.0.0.1:8443/apiman-gateway/Newcastle/CustomerService/"), I get this response : Server returned HTTP response code: 405 for URL: http://localhost:9090/rest/customerservice/customers QUESTION : Do I have to encode each service individually or can I encode them one time when I declare the API Endpoint of the "Service Implementation" ? Regards, -- Charles Moulliard Principal Solution Architect / JBoss Fuse Expert - Global Enablement @redhat cmoulliard at redhat.com | work: +31 205 65 12 84 | mobile: +32 473 604 014 MC-Square Business "Stockholm", Leonardo Da Vincilaan 19, Diegem 1831 - Belgium twitter: @cmoulliard | blog: cmoulliard.github.io committer: apache camel, karaf, servicemix, hawtio, fabric8, drools, jbpm, deltaspike -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20150708/4a0f65b6/attachment-0001.html From ldimaggi at redhat.com Wed Jul 8 22:06:11 2015 From: ldimaggi at redhat.com (Len DiMaggio) Date: Wed, 8 Jul 2015 22:06:11 -0400 (EDT) Subject: [Apiman-user] DZone: Manage Fuse APIs with APIMan In-Reply-To: <1019894056.34555272.1436389377261.JavaMail.zimbra@redhat.com> References: <1019894056.34555272.1436389377261.JavaMail.zimbra@redhat.com> Message-ID: <227290039.16381127.1436407571470.JavaMail.zimbra@redhat.com> Very nice! ----- Original Message ----- | From: "Stefan Bunciak" | To: apiman-user at lists.jboss.org | Cc: apiman-qe at redhat.com | Sent: Wednesday, July 8, 2015 5:02:57 PM | Subject: DZone: Manage Fuse APIs with APIMan | DZone just published my article about managing JBoss Fuse APIs by apiman | https://dzone.com/articles/manage-fuse-apis-with-apiman | -- | Stefan Bunciak | sbunciak at redhat.com | Red Hat JBoss Middleware Quality Engineering | RHCECD | RHCJA | RHCSA (CN: 120-138-367) -- Len DiMaggio (ldimaggi at redhat.com) JBoss by Red Hat 314 Littleton Road Westford, MA 01886 USA tel: 978.392.3179 cell: 781.472.9912 http://www.redhat.com http://community.jboss.org/people/ldimaggio -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20150708/ef25df0b/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: RHxJBpngthumb.png Type: image/png Size: 9435 bytes Desc: not available Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20150708/ef25df0b/attachment.png From cmoulliard at redhat.com Thu Jul 9 02:56:49 2015 From: cmoulliard at redhat.com (Charles Moulliard) Date: Thu, 9 Jul 2015 08:56:49 +0200 Subject: [Apiman-user] Mapping between REST services (GET/POST/PT/DELETE) & API Gateway In-Reply-To: <559D618F.5010706@redhat.com> References: <559D618F.5010706@redhat.com> Message-ID: <559E1B31.9040108@redhat.com> I have been able to find how to use the APIMan Gateway curl -k -H "Authorization: Bearer $TOKEN" https://127.0.0.1:8443/apiman-gateway/Newcastle/CustomerService/2.0/123 echo ">>> POST Customer : 124" curl -k -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -X POST -d '{"Customer":{"name":"Charles"}}' https://127.0.0.1:8443/apiman-gateway/Newcastle/CustomerService/2.0 echo ">>> GET Customer : 124" curl -k -H "Authorization: Bearer $TOKEN" https://127.0.0.1:8443/apiman-gateway/Newcastle/CustomerService/2.0/124 echo ">>> PUT Customer : 124" curl -k -H "Content-Type: application/json" -X PUT -d '{"Customer":{"id":124,"name":"SMALS"}}' -H "Authorization: Bearer $TOKEN" https://127.0.0.1:8443/apiman-gateway/Newcastle/CustomerService/2.0/ echo ">>> DEL Customer : 124" curl -v -k -X DEL -H "Authorization: Bearer $TOKEN" https://127.0.0.1:8443/apiman-gateway/Newcastle/CustomerService/2.0/124 echo ">>> GET Customer : 124" curl -k -H "Authorization: Bearer $TOKEN" https://127.0.0.1:8443/apiman-gateway/Newcastle/CustomerService/2.0/124 But the DEL HTTP operation is not supported : https://github.com/apiman/apiman/issues/152 On 08/07/15 19:44, Charles Moulliard wrote: > Hi, > > The API Manager allows to map the proxy service (= service to be > authorized) with the real service exposed by example by a REST Endpoint > > If the REST service exposes GET, PUT, DELETE & POST methods that we ca > nreach using these curl requests : > > 1) GET > curl http://localhost:8080/cxf/rest/customerservice/customers/123 > 2) POST > curl -i -H "Content-Type: application/json" -X POST -d > '{"Customer":{"name":"Charles"}}' > http://localhost:8080/cxf/rest/customerservice/customers > 3) PUT > curl -i -H "Content-Type: application/json" -X PUT -d > '{"Customer":{"id":124,"name":"TUG"}}' > http://localhost:8080/cxf/rest/customerservice/customers > 4) Delete > curl -X DEL > http://localhost:8080/cxf/rest/customerservice/customers/124 > > I have encoded this service API : > http://localhost:9090/rest/customerservice/customers/ but when I try > to reach it using the proxy API ("curl -v -k -H "Authorization: Bearer > $TOKEN" > https://127.0.0.1:8443/apiman-gateway/Newcastle/CustomerService/"), I > get this response : Server returned HTTP response code: 405 for URL: > http://localhost:9090/rest/customerservice/customers > > QUESTION : Do I have to encode each service individually or can I > encode them one time when I declare the API Endpoint of the "Service > Implementation" ? > > > Regards, > -- > Charles Moulliard > Principal Solution Architect / JBoss Fuse Expert - Global Enablement > @redhat > cmoulliard at redhat.com | work: +31 205 65 12 84 | mobile: +32 473 604 014 > MC-Square Business "Stockholm", Leonardo Da Vincilaan 19, Diegem 1831 > - Belgium > twitter: @cmoulliard | blog: > cmoulliard.github.io > committer: apache camel, karaf, servicemix, hawtio, fabric8, drools, > jbpm, deltaspike -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20150709/81d07df1/attachment.html From marc.savy at redhat.com Thu Jul 9 04:31:56 2015 From: marc.savy at redhat.com (Marc Savy) Date: Thu, 9 Jul 2015 09:31:56 +0100 Subject: [Apiman-user] Mapping between REST services (GET/POST/PT/DELETE) & API Gateway In-Reply-To: <559E1B31.9040108@redhat.com> References: <559D618F.5010706@redhat.com> <559E1B31.9040108@redhat.com> Message-ID: <559E317C.3030804@redhat.com> Just for everyone else's information (or anyone searching) - as we discussed on GitHub, there is no HTTP DEL, it's DELETE. i.e. curl -v -k -X DELETE -H "Authorization: Bearer $TOKEN" On 09/07/2015 07:56, Charles Moulliard wrote: > I have been able to find how to use the APIMan Gateway > > curl -k -H "Authorization: Bearer $TOKEN" > https://127.0.0.1:8443/apiman-gateway/Newcastle/CustomerService/2.0/123 > > echo ">>> POST Customer : 124" > > curl -k -H "Authorization: Bearer $TOKEN" -H "Content-Type: > application/json" -X POST -d '{"Customer":{"name":"Charles"}}' > https://127.0.0.1:8443/apiman-gateway/Newcastle/CustomerService/2.0 > > echo ">>> GET Customer : 124" > > curl -k -H "Authorization: Bearer $TOKEN" > https://127.0.0.1:8443/apiman-gateway/Newcastle/CustomerService/2.0/124 > > echo ">>> PUT Customer : 124" > > curl -k -H "Content-Type: application/json" -X PUT -d > '{"Customer":{"id":124,"name":"SMALS"}}' -H "Authorization: Bearer > $TOKEN" https://127.0.0.1:8443/apiman-gateway/Newcastle/CustomerService/2.0/ > > echo ">>> DEL Customer : 124" > > curl -v -k -X DEL -H "Authorization: Bearer $TOKEN" > https://127.0.0.1:8443/apiman-gateway/Newcastle/CustomerService/2.0/124 > > echo ">>> GET Customer : 124" > > curl -k -H "Authorization: Bearer $TOKEN" > https://127.0.0.1:8443/apiman-gateway/Newcastle/CustomerService/2.0/124 > > But the DEL HTTP operation is not supported : > https://github.com/apiman/apiman/issues/152 > > On 08/07/15 19:44, Charles Moulliard wrote: > > Hi, > > > > The API Manager allows to map the proxy service (= service to be > > authorized) with the real service exposed by example by a REST Endpoint > > > > If the REST service exposes GET, PUT, DELETE & POST methods that we ca > > nreach using these curl requests : > > > > 1) GET > > curl http://localhost:8080/cxf/rest/customerservice/customers/123 > > 2) POST > > curl -i -H "Content-Type: application/json" -X POST -d > > '{"Customer":{"name":"Charles"}}' > > http://localhost:8080/cxf/rest/customerservice/customers > > 3) PUT > > curl -i -H "Content-Type: application/json" -X PUT -d > > '{"Customer":{"id":124,"name":"TUG"}}' > > http://localhost:8080/cxf/rest/customerservice/customers > > 4) Delete > > curl -X DEL > > http://localhost:8080/cxf/rest/customerservice/customers/124 > > > > I have encoded this service API : > > http://localhost:9090/rest/customerservice/customers/ but when I try > > to reach it using the proxy API ("curl -v -k -H "Authorization: Bearer > > $TOKEN" > > https://127.0.0.1:8443/apiman-gateway/Newcastle/CustomerService/"), I > > get this response : Server returned HTTP response code: 405 for URL: > > http://localhost:9090/rest/customerservice/customers > > > > QUESTION : Do I have to encode each service individually or can I > > encode them one time when I declare the API Endpoint of the "Service > > Implementation" ? > > > > > > Regards, > > -- > > Charles Moulliard > > Principal Solution Architect / JBoss Fuse Expert - Global Enablement > > @redhat > > cmoulliard at redhat.com | work: +31 205 65 12 84 | mobile: +32 473 604 014 > > MC-Square Business "Stockholm", Leonardo Da Vincilaan 19, Diegem 1831 > > - Belgium > > twitter: @cmoulliard | blog: > > cmoulliard.github.io > > committer: apache camel, karaf, servicemix, hawtio, fabric8, drools, > > jbpm, deltaspike > > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From marc.savy at redhat.com Thu Jul 9 05:32:16 2015 From: marc.savy at redhat.com (Marc Savy) Date: Thu, 9 Jul 2015 10:32:16 +0100 Subject: [Apiman-user] Mapping between REST services (GET/POST/PT/DELETE) & API Gateway In-Reply-To: <559D618F.5010706@redhat.com> References: <559D618F.5010706@redhat.com> Message-ID: <559E3FA0.9060506@redhat.com> Hi Charles, > QUESTION : Do I have to encode each service individually or can I > encode them one time when I declare the API Endpoint of the > "Service > Implementation" ?> I'm not quite sure what you mean, so I'll try and illustrate generally. If I have a 'real' service whose based URL is: http://127.0.0.1/my-cool-service/ I decide I want to add it to apiman, and I put the above as the implementation API Endpoint. Depending what names I gave my organization, service, version, etc (and whether it is a public service, SSL config, ...), I might end up with an endpoint URL like so: https://localhost:8443/apiman-gateway/my-org/my-cool-service/1.0 Let's imagine that in the real service, we want to call: http://127.0.0.1/my-cool-service/bacon http://127.0.0.1/my-cool-service/omlette http://127.0.0.1/my-cool-service/escargot Through the gateway this would simply be: https://localhost:8443/apiman-gateway/my-org/my-cool-service/1.0/bacon https://localhost:8443/apiman-gateway/my-org/my-cool-service/1.0/omlette https://localhost:8443/apiman-gateway/my-org/my-cool-service/1.0/escargot Regards, Marc On 08/07/2015 18:44, Charles Moulliard wrote: > Hi, > > The API Manager allows to map the proxy service (= service to be > authorized) with the real service exposed by example by a REST Endpoint > > If the REST service exposes GET, PUT, DELETE & POST methods that we ca > nreach using these curl requests : > > 1) GET > curl http://localhost:8080/cxf/rest/customerservice/customers/123 > 2) POST > curl -i -H "Content-Type: application/json" -X POST -d > '{"Customer":{"name":"Charles"}}' > http://localhost:8080/cxf/rest/customerservice/customers > 3) PUT > curl -i -H "Content-Type: application/json" -X PUT -d > '{"Customer":{"id":124,"name":"TUG"}}' > http://localhost:8080/cxf/rest/customerservice/customers > 4) Delete > curl -X DEL > http://localhost:8080/cxf/rest/customerservice/customers/124 > > I have encoded this service API : > http://localhost:9090/rest/customerservice/customers/ but when I try to > reach it using the proxy API ("curl -v -k -H "Authorization: Bearer > $TOKEN" > https://127.0.0.1:8443/apiman-gateway/Newcastle/CustomerService/"), I > get this response : Server returned HTTP response code: 405 for URL: > http://localhost:9090/rest/customerservice/customers > > QUESTION : Do I have to encode each service individually or can I encode > them one time when I declare the API Endpoint of the "Service > Implementation" ? > > > Regards, > -- > Charles Moulliard > Principal Solution Architect / JBoss Fuse Expert - Global Enablement @redhat > cmoulliard at redhat.com | work: +31 205 65 12 84 | mobile: +32 473 604 014 > MC-Square Business "Stockholm", Leonardo Da Vincilaan 19, Diegem 1831 - > Belgium > twitter: @cmoulliard | blog: > cmoulliard.github.io > committer: apache camel, karaf, servicemix, hawtio, fabric8, drools, > jbpm, deltaspike > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From marc.savy at redhat.com Fri Jul 10 07:06:30 2015 From: marc.savy at redhat.com (Marc Savy) Date: Fri, 10 Jul 2015 12:06:30 +0100 Subject: [Apiman-user] Corrections to some recent blogpost walkthroughs Message-ID: <559FA736.1060700@redhat.com> Hi All, Someone a few of our recent apiman blogposts pointed out a few errors which may well have frustrated people's attempts to follow our 'worked-through' examples. I've now fixed those problems, so without further ado: Keycloak OAuth2 + apiman: http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/2015/06/09/keycloak-oauth2.html CORS: http://www.apiman.io/blog/security/plugin/policy/cors/2015/07/02/cors.html Also, while you're here, why not check out Eric & Stefan's recent blogs on Metrics & Fuse: http://www.apiman.io/blog/api-manager/service/ui/metrics/2015/07/06/metrics.html http://www.apiman.io/blog/api/management/jboss/fuse/2015/07/07/fuse-apis.html Regards, Marc From eric.wittmann at redhat.com Mon Jul 13 09:49:28 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Mon, 13 Jul 2015 09:49:28 -0400 Subject: [Apiman-user] DZone: Manage Fuse APIs with APIMan In-Reply-To: <227290039.16381127.1436407571470.JavaMail.zimbra@redhat.com> References: <1019894056.34555272.1436389377261.JavaMail.zimbra@redhat.com> <227290039.16381127.1436407571470.JavaMail.zimbra@redhat.com> Message-ID: <55A3C1E8.6090305@redhat.com> +1 On 7/8/2015 10:06 PM, Len DiMaggio wrote: > Very nice! > > ------------------------------------------------------------------------ > > *From: *"Stefan Bunciak" > *To: *apiman-user at lists.jboss.org > *Cc: *apiman-qe at redhat.com > *Sent: *Wednesday, July 8, 2015 5:02:57 PM > *Subject: *DZone: Manage Fuse APIs with APIMan > > DZone just published my article about managing JBoss Fuse APIs by > apiman https://dzone.com/articles/manage-fuse-apis-with-apiman > > -- > Stefan Bunciak > sbunciak at redhat.com > Red Hat JBoss Middleware Quality Engineering > > RHCECD | RHCJA | RHCSA (CN: 120-138-367) > > > > > -- > > Len DiMaggio (ldimaggi at redhat.com) > JBoss by Red Hat > 314 Littleton Road > Westford, MA 01886 USA > tel: 978.392.3179 > cell: 781.472.9912 > http://www.redhat.com > http://community.jboss.org/people/ldimaggio > > > > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From cmoulliard at redhat.com Mon Jul 13 13:20:19 2015 From: cmoulliard at redhat.com (Charles Moulliard) Date: Mon, 13 Jul 2015 19:20:19 +0200 Subject: [Apiman-user] REST Services to automate some tests Message-ID: <55A3F353.90603@redhat.com> Hi, Instead of creating manually the Keycloak realm, user, role, ... like also the Apiman Service, policy & plugin using their respective admin web site (http://localhost:8080/apimanui/ & http://localhost:8080/auth/admin ), do we have REST services (ApiMan, Keycloak) that I could use to to make a end to end test after installing ApiMan/Keycloak (Oauth2 Keyvloak policy by example) ? Regards, Charles From eric.wittmann at redhat.com Mon Jul 13 14:35:14 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Mon, 13 Jul 2015 14:35:14 -0400 Subject: [Apiman-user] REST Services to automate some tests In-Reply-To: <55A3F353.90603@redhat.com> References: <55A3F353.90603@redhat.com> Message-ID: <55A404E2.9080109@redhat.com> Both projects do have a set of REST endpoints so I believe this is possible. I don't know the capabilities of the keycloak APIs, however - that might be a question for them. Perhaps @msavy will know more. -Eric On 7/13/2015 1:20 PM, Charles Moulliard wrote: > Hi, > > Instead of creating manually the Keycloak realm, user, role, ... like > also the Apiman Service, policy & plugin using their respective admin > web site (http://localhost:8080/apimanui/ & > http://localhost:8080/auth/admin ), do we have REST services (ApiMan, > Keycloak) that I could use to to make a end to end test after installing > ApiMan/Keycloak (Oauth2 Keyvloak policy by example) ? > > Regards, > > Charles > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From cmoulliard at redhat.com Tue Jul 14 02:43:38 2015 From: cmoulliard at redhat.com (Charles Moulliard) Date: Tue, 14 Jul 2015 08:43:38 +0200 Subject: [Apiman-user] REST Services to automate some tests In-Reply-To: <55A404E2.9080109@redhat.com> References: <55A3F353.90603@redhat.com> <55A404E2.9080109@redhat.com> Message-ID: <55A4AF9A.7000400@redhat.com> Hi Eric, I think that in the meantime, I will use this test plan (https://github.com/apiman/apiman/tree/master/test/suite/src/test/java/io/apiman/test/suite) & will check if it can be extended to also include Keycloak Regards, Charles On 13/07/15 20:35, Eric Wittmann wrote: > Both projects do have a set of REST endpoints so I believe this is > possible. I don't know the capabilities of the keycloak APIs, however > - that might be a question for them. > > Perhaps @msavy will know more. > > -Eric > > On 7/13/2015 1:20 PM, Charles Moulliard wrote: >> Hi, >> >> Instead of creating manually the Keycloak realm, user, role, ... like >> also the Apiman Service, policy & plugin using their respective admin >> web site (http://localhost:8080/apimanui/ & >> http://localhost:8080/auth/admin ), do we have REST services (ApiMan, >> Keycloak) that I could use to to make a end to end test after installing >> ApiMan/Keycloak (Oauth2 Keyvloak policy by example) ? >> >> Regards, >> >> Charles >> _______________________________________________ >> Apiman-user mailing list >> Apiman-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/apiman-user >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20150714/25397cf7/attachment.html From marc.savy at redhat.com Tue Jul 14 03:30:23 2015 From: marc.savy at redhat.com (Marc Savy) Date: Tue, 14 Jul 2015 08:30:23 +0100 Subject: [Apiman-user] REST Services to automate some tests In-Reply-To: <55A404E2.9080109@redhat.com> References: <55A3F353.90603@redhat.com> <55A404E2.9080109@redhat.com> Message-ID: <55A4BA8F.7080300@redhat.com> Yes, you can do this in Keycloak via the API (create realms, users, clients, etc) or via JSON definition which you import into Keycloak. Regards, Marc On 13/07/2015 19:35, Eric Wittmann wrote: > Both projects do have a set of REST endpoints so I believe this is > possible. I don't know the capabilities of the keycloak APIs, however - > that might be a question for them. > > Perhaps @msavy will know more. > > -Eric > > On 7/13/2015 1:20 PM, Charles Moulliard wrote: >> Hi, >> >> Instead of creating manually the Keycloak realm, user, role, ... like >> also the Apiman Service, policy & plugin using their respective admin >> web site (http://localhost:8080/apimanui/ & >> http://localhost:8080/auth/admin ), do we have REST services (ApiMan, >> Keycloak) that I could use to to make a end to end test after installing >> ApiMan/Keycloak (Oauth2 Keyvloak policy by example) ? >> >> Regards, >> >> Charles >> _______________________________________________ >> Apiman-user mailing list >> Apiman-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/apiman-user >> > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From tdudgeon.ml at gmail.com Sun Jul 19 07:45:12 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Sun, 19 Jul 2015 12:45:12 +0100 Subject: [Apiman-user] apiman suitable for managing end users? Message-ID: <55AB8DC8.7070901@gmail.com> Hi I've been looking into apiman and like what I see, but have a conceptual question about its usage. I need something to manage the end users of my applications, not just the people who are developing and managing those applications. Is apiman suitable for this? e.g. each actual user of the applications would register to apiman and use their own access keys. I need this as I will want to handle metrics and usage on the level of the individual user. Also, if this was to be a sensible approach how does one configure the registration process. I understand apiman is using keycloak for this, but I see no link in the UI to configure keycloak. And I would need a way that new users could automatically be assigned to an organisation (e.g. a default organisation, or a specific one based on their email address). Tim From eric.wittmann at redhat.com Mon Jul 20 05:09:47 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Mon, 20 Jul 2015 05:09:47 -0400 Subject: [Apiman-user] apiman suitable for managing end users? In-Reply-To: <55AB8DC8.7070901@gmail.com> References: <55AB8DC8.7070901@gmail.com> Message-ID: <55ACBADB.3040102@redhat.com> Hi Tim. Interesting scenario. The typical scenario is that the apiman UI is only used by service providers and application developers. End users will typically not use the apiman UI. However, that doesn't mean apiman can't track end users. If authentication is enabled (either BASIC or OAuth2), then rate limiting can be configured on a per-user basis. When you configure the rate limit policy, you can choose "user" as an option and then provide the HTTP header containing the user. When configuring the authentication policy (which must come first in the policy chain) you would need to enable forwarding of the username. In addition, the next version of apiman will also include the authenticated user in the metrics data. This would allow you to query the elasticsearch metrics information by username. We won't have any specific support in the UI for breaking down metrics by user, at least not right away, but it will be in the data at least. Of course, you *can* use apiman the way you are suggesting. But as you observed there are some challenges. We don't currently have a way to assign roles to users automatically when they register. It would need to be a feature request I think: https://issues.jboss.org/browse/APIMAN I think if we added a very generic "user registration" extension point to apiman, then you could write your own custom handler to do whatever you want. Such a handler would be invoked the first time a new user logged into apiman. You could drive off their email address, roles, whatever. You could also provide a handler via a plugin. Thoughts? :) -Eric On 7/19/2015 7:45 AM, Tim Dudgeon wrote: > Hi > > I've been looking into apiman and like what I see, but have a conceptual > question about its usage. > I need something to manage the end users of my applications, not just > the people who are developing and managing those applications. Is apiman > suitable for this? e.g. each actual user of the applications would > register to apiman and use their own access keys. I need this as I will > want to handle metrics and usage on the level of the individual user. > > Also, if this was to be a sensible approach how does one configure the > registration process. I understand apiman is using keycloak for this, > but I see no link in the UI to configure keycloak. And I would need a > way that new users could automatically be assigned to an organisation > (e.g. a default organisation, or a specific one based on their email > address). > > Tim > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From tdudgeon.ml at gmail.com Mon Jul 20 15:33:24 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Mon, 20 Jul 2015 20:33:24 +0100 Subject: [Apiman-user] apiman suitable for managing end users? In-Reply-To: <55ACBADB.3040102@redhat.com> References: <55AB8DC8.7070901@gmail.com> <55ACBADB.3040102@redhat.com> Message-ID: <55AD4D04.2040702@gmail.com> Eric, Thoughts? Well, what you wrote raises many! 1. so it would seem that the best approach for now at least is to handle end user authentication completely separately and just pass through the user id? Or is it possible somehow to use the same keycloak server for this (apiman does use keyclock?) so that all users first have to register as an end user before they can get "promoted" to service provider or developer status within apiman? 2. automatically assigning roles on registration sounds like a good idea, though I suspect that working out how to do this will be tricky as there will be lots of different scenarios. I'll raise a JIRA issue on this, but will wait a day or so unless anyone else want to chip in here first. 3. By a "generic user registration extension" did you have in mind something like a "post registration" (javascript) hook? Tim On 20/07/2015 10:09, Eric Wittmann wrote: > Hi Tim. > > Interesting scenario. The typical scenario is that the apiman UI is > only used by service providers and application developers. End users > will typically not use the apiman UI. However, that doesn't mean > apiman can't track end users. If authentication is enabled (either > BASIC or OAuth2), then rate limiting can be configured on a per-user > basis. When you configure the rate limit policy, you can choose > "user" as an option and then provide the HTTP header containing the > user. When configuring the authentication policy (which must come > first in the policy chain) you would need to enable forwarding of the > username. > > In addition, the next version of apiman will also include the > authenticated user in the metrics data. This would allow you to query > the elasticsearch metrics information by username. We won't have any > specific support in the UI for breaking down metrics by user, at least > not right away, but it will be in the data at least. > > Of course, you *can* use apiman the way you are suggesting. But as > you observed there are some challenges. We don't currently have a way > to assign roles to users automatically when they register. It would > need to be a feature request I think: > > https://issues.jboss.org/browse/APIMAN > > I think if we added a very generic "user registration" extension point > to apiman, then you could write your own custom handler to do whatever > you want. Such a handler would be invoked the first time a new user > logged into apiman. You could drive off their email address, roles, > whatever. You could also provide a handler via a plugin. > > Thoughts? :) > > -Eric > > > On 7/19/2015 7:45 AM, Tim Dudgeon wrote: >> Hi >> >> I've been looking into apiman and like what I see, but have a conceptual >> question about its usage. >> I need something to manage the end users of my applications, not just >> the people who are developing and managing those applications. Is apiman >> suitable for this? e.g. each actual user of the applications would >> register to apiman and use their own access keys. I need this as I will >> want to handle metrics and usage on the level of the individual user. >> >> Also, if this was to be a sensible approach how does one configure the >> registration process. I understand apiman is using keycloak for this, >> but I see no link in the UI to configure keycloak. And I would need a >> way that new users could automatically be assigned to an organisation >> (e.g. a default organisation, or a specific one based on their email >> address). >> >> Tim >> _______________________________________________ >> Apiman-user mailing list >> Apiman-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/apiman-user >> From arun.gupta at gmail.com Mon Jul 20 19:11:49 2015 From: arun.gupta at gmail.com (Arun Gupta) Date: Mon, 20 Jul 2015 16:11:49 -0700 Subject: [Apiman-user] REST Sample Message-ID: 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 From eric.wittmann at redhat.com Tue Jul 21 07:11:10 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 21 Jul 2015 07:11:10 -0400 Subject: [Apiman-user] REST Sample In-Reply-To: References: Message-ID: <55AE28CE.3040802@redhat.com> 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 > From arun.gupta at gmail.com Tue Jul 21 17:06:15 2015 From: arun.gupta at gmail.com (Arun Gupta) Date: Tue, 21 Jul 2015 17:06:15 -0400 Subject: [Apiman-user] REST Sample In-Reply-To: <55AE28CE.3040802@redhat.com> References: <55AE28CE.3040802@redhat.com> Message-ID: 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 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 From eric.wittmann at redhat.com Tue Jul 21 18:11:52 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 21 Jul 2015 18:11:52 -0400 Subject: [Apiman-user] REST Sample In-Reply-To: References: <55AE28CE.3040802@redhat.com> Message-ID: <55AEC3A8.5090309@redhat.com> 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 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 >>> >> > > > From arun.gupta at gmail.com Tue Jul 21 22:19:44 2015 From: arun.gupta at gmail.com (Arun Gupta) Date: Tue, 21 Jul 2015 22:19:44 -0400 Subject: [Apiman-user] REST Sample In-Reply-To: <55AEC3A8.5090309@redhat.com> References: <55AE28CE.3040802@redhat.com> <55AEC3A8.5090309@redhat.com> Message-ID: 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 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 >> 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 From eric.wittmann at redhat.com Wed Jul 22 08:33:03 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Wed, 22 Jul 2015 08:33:03 -0400 Subject: [Apiman-user] REST Sample In-Reply-To: References: <55AE28CE.3040802@redhat.com> <55AEC3A8.5090309@redhat.com> Message-ID: <55AF8D7F.30205@redhat.com> 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 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 >>> 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 >>>>> >>>> >>> >>> >>> >> > > > From arun.gupta at gmail.com Wed Jul 22 09:02:39 2015 From: arun.gupta at gmail.com (Arun Gupta) Date: Wed, 22 Jul 2015 09:02:39 -0400 Subject: [Apiman-user] REST Sample In-Reply-To: <55AF8D7F.30205@redhat.com> References: <55AE28CE.3040802@redhat.com> <55AEC3A8.5090309@redhat.com> <55AF8D7F.30205@redhat.com> Message-ID: 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 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 >> 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 >>>> >>>> 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 From eric.wittmann at redhat.com Wed Jul 22 10:17:01 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Wed, 22 Jul 2015 10:17:01 -0400 Subject: [Apiman-user] REST Sample In-Reply-To: References: <55AE28CE.3040802@redhat.com> <55AEC3A8.5090309@redhat.com> <55AF8D7F.30205@redhat.com> Message-ID: <55AFA5DD.7090408@redhat.com> 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 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 >>> 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 >>>>> >>>>> 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 >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> > > > From eric.wittmann at redhat.com Wed Jul 22 11:49:24 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Wed, 22 Jul 2015 11:49:24 -0400 Subject: [Apiman-user] Announcement: version 1.1.5.Final Message-ID: <55AFBB84.40002@redhat.com> Hello again everyone. A new version of apiman has been released. http://apiman.io/ The latest version is now 1.1.5.Final. You can find the release notes here: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12314121&version=12327612 This release is mostly bug fixes, particularly a couple of ugly ones introduced in 1.1.4.Final. Of note is that our mysql and postgres DDLs should be correct for this version. Also note that you can now use custom implementations of various apiman core components (e.g. the storage layer, or the metrics layer) by contributing them via plugins! This is great if you want to customize apiman, but you'll obviously need to know what you're doing. But, for example, if you want to store the API Manager data in mongodb instead of JPA or Elasticsearch, you can now provide a mongodb storage implementation in a plugin. So there's no need to rebuild apiman or futz with getting your code on the classpath. -Eric From ijlal.hzt at gmail.com Wed Jul 22 12:07:30 2015 From: ijlal.hzt at gmail.com (Ijlal EL HAZITI) Date: Wed, 22 Jul 2015 18:07:30 +0200 Subject: [Apiman-user] Communication with other systems Message-ID: Hi all, I want to build a demonstrator using a ESB, Apiman and my APIs so I'd like to know how Apiman communicates with other systems (Rest, API, SOAP..)? What interfaces does it supply? thank you -- Cordialement IjlaL EL HAZITI *Etudiant Ing?nieur Etudes et D?veloppement* *UBO - Master Professionnel de d?veloppement ? l'offshore des SI* *FSK - Master Sp?cialis? Qualit? du Logiciel* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20150722/4be20245/attachment.html From eric.wittmann at redhat.com Wed Jul 22 12:41:24 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Wed, 22 Jul 2015 12:41:24 -0400 Subject: [Apiman-user] Communication with other systems In-Reply-To: References: Message-ID: <55AFC7B4.4040303@redhat.com> Out of the box, apiman listens on HTTP and communicates with back-end services also on HTTP. However, the connector layer is fully pluggable (the part where the apiman Gateway invokes the back-end service). So it would not be difficult to provide a custom connector for something other than HTTP. In fact, with the latest version of apiman (1.1.5.Final) you can actually provide a custom connector factory via a plugin - no need to change apiman core code at all. Also note that the apiman gateway is fully embeddable - so if you wanted to run the gateway within some larger integrated solution that would be possible (though obviously more difficult). Note that it is our intention longer term to provide connectors for protocols other than http(s). However, that is not yet complete. -Eric On 7/22/2015 12:07 PM, Ijlal EL HAZITI wrote: > Hi all, > > I want to build a demonstrator using a ESB, Apiman and my APIs > > so I'd like to know how Apiman communicates with other systems (Rest, > API, SOAP..)? What interfaces does it supply? > > thank you > -- > Cordialement > IjlaL EL HAZITI > * > * > *Etudiant Ing?nieur Etudes et D?veloppement* > *UBO - Master Professionnel de d?veloppement ? l'offshore des SI > * > *FSK - Master Sp?cialis? Qualit? du Logiciel* > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From arun.gupta at gmail.com Wed Jul 22 18:49:52 2015 From: arun.gupta at gmail.com (Arun Gupta) Date: Wed, 22 Jul 2015 18:49:52 -0400 Subject: [Apiman-user] REST Sample In-Reply-To: <55AFA5DD.7090408@redhat.com> References: <55AE28CE.3040802@redhat.com> <55AEC3A8.5090309@redhat.com> <55AF8D7F.30205@redhat.com> <55AFA5DD.7090408@redhat.com> Message-ID: 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 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 >> 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 >>>> >>>> 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 >>>>>> >>>>>> 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 From arun.gupta at gmail.com Wed Jul 22 23:44:19 2015 From: arun.gupta at gmail.com (Arun Gupta) Date: Wed, 22 Jul 2015 21:44:19 -0600 Subject: [Apiman-user] Creating resources using Docker image Message-ID: I've created a Dockerfile [1] that will attempt to create different resources. Is there any standard format where I can drop .yml in a pre-defined directory and API Man will read the resources defined there and create them? This will simplify how the resources are created using Docker. The samples at [2] do not show that. [1] https://github.com/arun-gupta/microservices/blob/master/microservice/docker/Dockerfile [2] https://registry.hub.docker.com/u/jboss/apiman-wildfly/ Arun -- http://blog.arungupta.me http://twitter.com/arungupta From tdudgeon.ml at gmail.com Thu Jul 23 03:47:43 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Thu, 23 Jul 2015 08:47:43 +0100 Subject: [Apiman-user] Creating resources using Docker image In-Reply-To: References: Message-ID: <55B09C1F.4090300@gmail.com> This indeed would be very useful. Tim On 23/07/2015 04:44, Arun Gupta wrote: > I've created a Dockerfile [1] that will attempt to create different > resources. Is there any standard format where I can drop > .yml in a pre-defined directory and API Man will read > the resources defined there and create them? > > This will simplify how the resources are created using Docker. The > samples at [2] do not show that. > > [1] https://github.com/arun-gupta/microservices/blob/master/microservice/docker/Dockerfile > [2] https://registry.hub.docker.com/u/jboss/apiman-wildfly/ > > Arun > From jcechace at gmail.com Thu Jul 23 04:40:03 2015 From: jcechace at gmail.com (=?UTF-8?B?SmFrdWIgxIxlY2jDocSNZWs=?=) Date: Thu, 23 Jul 2015 10:40:03 +0200 Subject: [Apiman-user] REST Sample In-Reply-To: References: <55AE28CE.3040802@redhat.com> <55AEC3A8.5090309@redhat.com> <55AF8D7F.30205@redhat.com> <55AFA5DD.7090408@redhat.com> Message-ID: > 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 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 > 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> > >> 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 > >>>> > >>>> 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 > >>>>>> > >>>>>> 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 > https://lists.jboss.org/mailman/listinfo/apiman-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20150723/ce454f0a/attachment-0001.html From eric.wittmann at redhat.com Thu Jul 23 07:27:36 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 23 Jul 2015 07:27:36 -0400 Subject: [Apiman-user] REST Sample In-Reply-To: References: <55AE28CE.3040802@redhat.com> <55AEC3A8.5090309@redhat.com> <55AF8D7F.30205@redhat.com> <55AFA5DD.7090408@redhat.com> Message-ID: <55B0CFA8.4050107@redhat.com> 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 > 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 > > 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 > > > >> 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 > >>>> > > >>>> 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 > >>>>>> > > >>>>>> 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 > https://lists.jboss.org/mailman/listinfo/apiman-user > > From eric.wittmann at redhat.com Thu Jul 23 07:32:19 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 23 Jul 2015 07:32:19 -0400 Subject: [Apiman-user] Creating resources using Docker image In-Reply-To: <55B09C1F.4090300@gmail.com> References: <55B09C1F.4090300@gmail.com> Message-ID: <55B0D0C3.9060603@redhat.com> That is not currently a feature. But I've now added a JIRA for it, since it seems like a nice idea (especially for extending the docker container). https://issues.jboss.org/browse/APIMAN-566 -Eric On 7/23/2015 3:47 AM, Tim Dudgeon wrote: > This indeed would be very useful. > Tim > > On 23/07/2015 04:44, Arun Gupta wrote: >> I've created a Dockerfile [1] that will attempt to create different >> resources. Is there any standard format where I can drop >> .yml in a pre-defined directory and API Man will read >> the resources defined there and create them? >> >> This will simplify how the resources are created using Docker. The >> samples at [2] do not show that. >> >> [1] https://github.com/arun-gupta/microservices/blob/master/microservice/docker/Dockerfile >> [2] https://registry.hub.docker.com/u/jboss/apiman-wildfly/ >> >> Arun >> > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From arun.gupta at gmail.com Thu Jul 23 07:35:11 2015 From: arun.gupta at gmail.com (Arun Gupta) Date: Thu, 23 Jul 2015 05:35:11 -0600 Subject: [Apiman-user] Creating resources using Docker image In-Reply-To: <55B0D0C3.9060603@redhat.com> References: <55B09C1F.4090300@gmail.com> <55B0D0C3.9060603@redhat.com> Message-ID: Thanks! What is the recommended design pattern to extend the Dockerfile in the meanwhile? Arun On Thu, Jul 23, 2015 at 5:32 AM, Eric Wittmann wrote: > That is not currently a feature. But I've now added a JIRA for it, > since it seems like a nice idea (especially for extending the docker > container). > > https://issues.jboss.org/browse/APIMAN-566 > > -Eric > > On 7/23/2015 3:47 AM, Tim Dudgeon wrote: >> This indeed would be very useful. >> Tim >> >> On 23/07/2015 04:44, Arun Gupta wrote: >>> I've created a Dockerfile [1] that will attempt to create different >>> resources. Is there any standard format where I can drop >>> .yml in a pre-defined directory and API Man will read >>> the resources defined there and create them? >>> >>> This will simplify how the resources are created using Docker. The >>> samples at [2] do not show that. >>> >>> [1] https://github.com/arun-gupta/microservices/blob/master/microservice/docker/Dockerfile >>> [2] https://registry.hub.docker.com/u/jboss/apiman-wildfly/ >>> >>> Arun >>> >> >> _______________________________________________ >> Apiman-user mailing list >> Apiman-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/apiman-user >> > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user -- http://blog.arungupta.me http://twitter.com/arungupta From eric.wittmann at redhat.com Thu Jul 23 07:35:40 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 23 Jul 2015 07:35:40 -0400 Subject: [Apiman-user] REST Sample In-Reply-To: References: <55AE28CE.3040802@redhat.com> <55AEC3A8.5090309@redhat.com> <55AF8D7F.30205@redhat.com> <55AFA5DD.7090408@redhat.com> Message-ID: <55B0D18C.3030200@redhat.com> One other point, after clicking though Jakub's linked presentation on API design. The funny thing about REST is that many disagree with how certain goals should be accomplished. With respect to versioning, many people really hate having the version # in the URL. I actually prefer it because it's much simpler for clients (no need to configure custom headers or odd Accept header values). However I'm not the only user of apiman, so to that end: https://issues.jboss.org/browse/APIMAN-558 https://issues.jboss.org/browse/APIMAN-557 We should be able to simultaneously support all three styles of versioning. -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 > 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 > > 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 > > > >> 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 > >>>> > > >>>> 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 > >>>>>> > > >>>>>> 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 > https://lists.jboss.org/mailman/listinfo/apiman-user > > From eric.wittmann at redhat.com Thu Jul 23 07:45:13 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 23 Jul 2015 07:45:13 -0400 Subject: [Apiman-user] Creating resources using Docker image In-Reply-To: References: <55B09C1F.4090300@gmail.com> <55B0D0C3.9060603@redhat.com> Message-ID: <55B0D3C9.3030400@redhat.com> You are probably more deft with docker than I am, but perhaps a shell script could be used to send a bunch of curl commands? -Eric On 7/23/2015 7:35 AM, Arun Gupta wrote: > Thanks! > > What is the recommended design pattern to extend the Dockerfile in the > meanwhile? > > Arun > > On Thu, Jul 23, 2015 at 5:32 AM, Eric Wittmann wrote: >> That is not currently a feature. But I've now added a JIRA for it, >> since it seems like a nice idea (especially for extending the docker >> container). >> >> https://issues.jboss.org/browse/APIMAN-566 >> >> -Eric >> >> On 7/23/2015 3:47 AM, Tim Dudgeon wrote: >>> This indeed would be very useful. >>> Tim >>> >>> On 23/07/2015 04:44, Arun Gupta wrote: >>>> I've created a Dockerfile [1] that will attempt to create different >>>> resources. Is there any standard format where I can drop >>>> .yml in a pre-defined directory and API Man will read >>>> the resources defined there and create them? >>>> >>>> This will simplify how the resources are created using Docker. The >>>> samples at [2] do not show that. >>>> >>>> [1] https://github.com/arun-gupta/microservices/blob/master/microservice/docker/Dockerfile >>>> [2] https://registry.hub.docker.com/u/jboss/apiman-wildfly/ >>>> >>>> Arun >>>> >>> >>> _______________________________________________ >>> Apiman-user mailing list >>> Apiman-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/apiman-user >>> >> _______________________________________________ >> Apiman-user mailing list >> Apiman-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/apiman-user > > > From arun.gupta at gmail.com Thu Jul 23 07:48:05 2015 From: arun.gupta at gmail.com (Arun Gupta) Date: Thu, 23 Jul 2015 05:48:05 -0600 Subject: [Apiman-user] Creating resources using Docker image In-Reply-To: <55B0D3C9.3030400@redhat.com> References: <55B09C1F.4090300@gmail.com> <55B0D0C3.9060603@redhat.com> <55B0D3C9.3030400@redhat.com> Message-ID: I've been thinking something on those lines. - Invoke shell script from Dockerfile - Start API Man - Run shell scripts - Shut it down - Go back to Dockerfile which will then start it Will share something, stay tuned. Arun On Thu, Jul 23, 2015 at 5:45 AM, Eric Wittmann wrote: > You are probably more deft with docker than I am, but perhaps a shell script > could be used to send a bunch of curl commands? > > -Eric > > On 7/23/2015 7:35 AM, Arun Gupta wrote: >> >> Thanks! >> >> What is the recommended design pattern to extend the Dockerfile in the >> meanwhile? >> >> Arun >> >> On Thu, Jul 23, 2015 at 5:32 AM, Eric Wittmann >> wrote: >>> >>> That is not currently a feature. But I've now added a JIRA for it, >>> since it seems like a nice idea (especially for extending the docker >>> container). >>> >>> https://issues.jboss.org/browse/APIMAN-566 >>> >>> -Eric >>> >>> On 7/23/2015 3:47 AM, Tim Dudgeon wrote: >>>> >>>> This indeed would be very useful. >>>> Tim >>>> >>>> On 23/07/2015 04:44, Arun Gupta wrote: >>>>> >>>>> I've created a Dockerfile [1] that will attempt to create different >>>>> resources. Is there any standard format where I can drop >>>>> .yml in a pre-defined directory and API Man will read >>>>> the resources defined there and create them? >>>>> >>>>> This will simplify how the resources are created using Docker. The >>>>> samples at [2] do not show that. >>>>> >>>>> [1] >>>>> https://github.com/arun-gupta/microservices/blob/master/microservice/docker/Dockerfile >>>>> [2] https://registry.hub.docker.com/u/jboss/apiman-wildfly/ >>>>> >>>>> Arun >>>>> >>>> >>>> _______________________________________________ >>>> Apiman-user mailing list >>>> Apiman-user at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/apiman-user >>>> >>> _______________________________________________ >>> Apiman-user mailing list >>> Apiman-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/apiman-user >> >> >> >> > -- http://blog.arungupta.me http://twitter.com/arungupta From tdudgeon.ml at gmail.com Thu Jul 23 09:13:11 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Thu, 23 Jul 2015 14:13:11 +0100 Subject: [Apiman-user] apiman suitable for managing end users? In-Reply-To: <55ACBADB.3040102@redhat.com> References: <55AB8DC8.7070901@gmail.com> <55ACBADB.3040102@redhat.com> Message-ID: <55B0E867.1050602@gmail.com> No further comments so I created an issue for this: https://issues.jboss.org/browse/APIMAN-569 On 20/07/2015 10:09, Eric Wittmann wrote: > Hi Tim. > > Interesting scenario. The typical scenario is that the apiman UI is > only used by service providers and application developers. End users > will typically not use the apiman UI. However, that doesn't mean > apiman can't track end users. If authentication is enabled (either > BASIC or OAuth2), then rate limiting can be configured on a per-user > basis. When you configure the rate limit policy, you can choose > "user" as an option and then provide the HTTP header containing the > user. When configuring the authentication policy (which must come > first in the policy chain) you would need to enable forwarding of the > username. > > In addition, the next version of apiman will also include the > authenticated user in the metrics data. This would allow you to query > the elasticsearch metrics information by username. We won't have any > specific support in the UI for breaking down metrics by user, at least > not right away, but it will be in the data at least. > > Of course, you *can* use apiman the way you are suggesting. But as > you observed there are some challenges. We don't currently have a way > to assign roles to users automatically when they register. It would > need to be a feature request I think: > > https://issues.jboss.org/browse/APIMAN > > I think if we added a very generic "user registration" extension point > to apiman, then you could write your own custom handler to do whatever > you want. Such a handler would be invoked the first time a new user > logged into apiman. You could drive off their email address, roles, > whatever. You could also provide a handler via a plugin. > > Thoughts? :) > > -Eric > > > On 7/19/2015 7:45 AM, Tim Dudgeon wrote: >> Hi >> >> I've been looking into apiman and like what I see, but have a conceptual >> question about its usage. >> I need something to manage the end users of my applications, not just >> the people who are developing and managing those applications. Is apiman >> suitable for this? e.g. each actual user of the applications would >> register to apiman and use their own access keys. I need this as I will >> want to handle metrics and usage on the level of the individual user. >> >> Also, if this was to be a sensible approach how does one configure the >> registration process. I understand apiman is using keycloak for this, >> but I see no link in the UI to configure keycloak. And I would need a >> way that new users could automatically be assigned to an organisation >> (e.g. a default organisation, or a specific one based on their email >> address). >> >> Tim >> _______________________________________________ >> Apiman-user mailing list >> Apiman-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/apiman-user >> From eric.wittmann at redhat.com Thu Jul 23 09:34:09 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 23 Jul 2015 09:34:09 -0400 Subject: [Apiman-user] Creating resources using Docker image In-Reply-To: References: <55B09C1F.4090300@gmail.com> <55B0D0C3.9060603@redhat.com> <55B0D3C9.3030400@redhat.com> Message-ID: <55B0ED51.2050804@redhat.com> I think it would be possible to have a run-once shell script. Either by writing/checking some sort of "already run" file. Or else by querying apiman to see if a particular entity exists. For example, query to see if "My-Custom-Organization" exists ... if it does then skip the script. If not, then run the multitude of curl commands to do what you want. -Eric On 7/23/2015 7:48 AM, Arun Gupta wrote: > I've been thinking something on those lines. > > - Invoke shell script from Dockerfile > - Start API Man > - Run shell scripts > - Shut it down > - Go back to Dockerfile which will then start it > > Will share something, stay tuned. > > Arun > > On Thu, Jul 23, 2015 at 5:45 AM, Eric Wittmann wrote: >> You are probably more deft with docker than I am, but perhaps a shell script >> could be used to send a bunch of curl commands? >> >> -Eric >> >> On 7/23/2015 7:35 AM, Arun Gupta wrote: >>> >>> Thanks! >>> >>> What is the recommended design pattern to extend the Dockerfile in the >>> meanwhile? >>> >>> Arun >>> >>> On Thu, Jul 23, 2015 at 5:32 AM, Eric Wittmann >>> wrote: >>>> >>>> That is not currently a feature. But I've now added a JIRA for it, >>>> since it seems like a nice idea (especially for extending the docker >>>> container). >>>> >>>> https://issues.jboss.org/browse/APIMAN-566 >>>> >>>> -Eric >>>> >>>> On 7/23/2015 3:47 AM, Tim Dudgeon wrote: >>>>> >>>>> This indeed would be very useful. >>>>> Tim >>>>> >>>>> On 23/07/2015 04:44, Arun Gupta wrote: >>>>>> >>>>>> I've created a Dockerfile [1] that will attempt to create different >>>>>> resources. Is there any standard format where I can drop >>>>>> .yml in a pre-defined directory and API Man will read >>>>>> the resources defined there and create them? >>>>>> >>>>>> This will simplify how the resources are created using Docker. The >>>>>> samples at [2] do not show that. >>>>>> >>>>>> [1] >>>>>> https://github.com/arun-gupta/microservices/blob/master/microservice/docker/Dockerfile >>>>>> [2] https://registry.hub.docker.com/u/jboss/apiman-wildfly/ >>>>>> >>>>>> Arun >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Apiman-user mailing list >>>>> Apiman-user at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/apiman-user >>>>> >>>> _______________________________________________ >>>> Apiman-user mailing list >>>> Apiman-user at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/apiman-user >>> >>> >>> >>> >> > > > From eric.wittmann at redhat.com Thu Jul 23 09:34:28 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 23 Jul 2015 09:34:28 -0400 Subject: [Apiman-user] apiman suitable for managing end users? In-Reply-To: <55B0E867.1050602@gmail.com> References: <55AB8DC8.7070901@gmail.com> <55ACBADB.3040102@redhat.com> <55B0E867.1050602@gmail.com> Message-ID: <55B0ED64.2020505@redhat.com> +1 thanks. On 7/23/2015 9:13 AM, Tim Dudgeon wrote: > No further comments so I created an issue for this: > https://issues.jboss.org/browse/APIMAN-569 > > On 20/07/2015 10:09, Eric Wittmann wrote: >> Hi Tim. >> >> Interesting scenario. The typical scenario is that the apiman UI is >> only used by service providers and application developers. End users >> will typically not use the apiman UI. However, that doesn't mean >> apiman can't track end users. If authentication is enabled (either >> BASIC or OAuth2), then rate limiting can be configured on a per-user >> basis. When you configure the rate limit policy, you can choose >> "user" as an option and then provide the HTTP header containing the >> user. When configuring the authentication policy (which must come >> first in the policy chain) you would need to enable forwarding of the >> username. >> >> In addition, the next version of apiman will also include the >> authenticated user in the metrics data. This would allow you to query >> the elasticsearch metrics information by username. We won't have any >> specific support in the UI for breaking down metrics by user, at least >> not right away, but it will be in the data at least. >> >> Of course, you *can* use apiman the way you are suggesting. But as >> you observed there are some challenges. We don't currently have a way >> to assign roles to users automatically when they register. It would >> need to be a feature request I think: >> >> https://issues.jboss.org/browse/APIMAN >> >> I think if we added a very generic "user registration" extension point >> to apiman, then you could write your own custom handler to do whatever >> you want. Such a handler would be invoked the first time a new user >> logged into apiman. You could drive off their email address, roles, >> whatever. You could also provide a handler via a plugin. >> >> Thoughts? :) >> >> -Eric >> >> >> On 7/19/2015 7:45 AM, Tim Dudgeon wrote: >>> Hi >>> >>> I've been looking into apiman and like what I see, but have a conceptual >>> question about its usage. >>> I need something to manage the end users of my applications, not just >>> the people who are developing and managing those applications. Is apiman >>> suitable for this? e.g. each actual user of the applications would >>> register to apiman and use their own access keys. I need this as I will >>> want to handle metrics and usage on the level of the individual user. >>> >>> Also, if this was to be a sensible approach how does one configure the >>> registration process. I understand apiman is using keycloak for this, >>> but I see no link in the UI to configure keycloak. And I would need a >>> way that new users could automatically be assigned to an organisation >>> (e.g. a default organisation, or a specific one based on their email >>> address). >>> >>> Tim >>> _______________________________________________ >>> Apiman-user mailing list >>> Apiman-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/apiman-user >>> > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From kbabo at redhat.com Thu Jul 23 10:28:49 2015 From: kbabo at redhat.com (Keith Babo) Date: Thu, 23 Jul 2015 10:28:49 -0400 Subject: [Apiman-user] Creating resources using Docker image In-Reply-To: <55B0ED51.2050804@redhat.com> References: <55B09C1F.4090300@gmail.com> <55B0D0C3.9060603@redhat.com> <55B0D3C9.3030400@redhat.com> <55B0ED51.2050804@redhat.com> Message-ID: Interesting discussion. Another aspect to consider here is how the docker image will work with various deployment architectures. For the ?kick the tires? use case, I expect you will want all of apiman (admin server/console, gateway) and all of the configuration built into your image. Makes it really easy to get off and running with a known state. In the ?production? use case, I wonder if things will change a bit. In that scenario, I can see the need for separate images for the gateway and for the admin server/console. This would allow the gateway containers to scale up independent of the admin container. Does baking the config into the image make sense here? Maybe it does for initial configuration, but you?ll also need a way to pull configuration into new gateway containers as they scale up. cheers, keith > On Jul 23, 2015, at 9:34 AM, Eric Wittmann wrote: > > I think it would be possible to have a run-once shell script. Either by > writing/checking some sort of "already run" file. Or else by querying > apiman to see if a particular entity exists. For example, query to see > if "My-Custom-Organization" exists ... if it does then skip the script. > If not, then run the multitude of curl commands to do what you want. > > -Eric > > On 7/23/2015 7:48 AM, Arun Gupta wrote: >> I've been thinking something on those lines. >> >> - Invoke shell script from Dockerfile >> - Start API Man >> - Run shell scripts >> - Shut it down >> - Go back to Dockerfile which will then start it >> >> Will share something, stay tuned. >> >> Arun >> >> On Thu, Jul 23, 2015 at 5:45 AM, Eric Wittmann wrote: >>> You are probably more deft with docker than I am, but perhaps a shell script >>> could be used to send a bunch of curl commands? >>> >>> -Eric >>> >>> On 7/23/2015 7:35 AM, Arun Gupta wrote: >>>> >>>> Thanks! >>>> >>>> What is the recommended design pattern to extend the Dockerfile in the >>>> meanwhile? >>>> >>>> Arun >>>> >>>> On Thu, Jul 23, 2015 at 5:32 AM, Eric Wittmann >>>> wrote: >>>>> >>>>> That is not currently a feature. But I've now added a JIRA for it, >>>>> since it seems like a nice idea (especially for extending the docker >>>>> container). >>>>> >>>>> https://issues.jboss.org/browse/APIMAN-566 >>>>> >>>>> -Eric >>>>> >>>>> On 7/23/2015 3:47 AM, Tim Dudgeon wrote: >>>>>> >>>>>> This indeed would be very useful. >>>>>> Tim >>>>>> >>>>>> On 23/07/2015 04:44, Arun Gupta wrote: >>>>>>> >>>>>>> I've created a Dockerfile [1] that will attempt to create different >>>>>>> resources. Is there any standard format where I can drop >>>>>>> .yml in a pre-defined directory and API Man will read >>>>>>> the resources defined there and create them? >>>>>>> >>>>>>> This will simplify how the resources are created using Docker. The >>>>>>> samples at [2] do not show that. >>>>>>> >>>>>>> [1] >>>>>>> https://github.com/arun-gupta/microservices/blob/master/microservice/docker/Dockerfile >>>>>>> [2] https://registry.hub.docker.com/u/jboss/apiman-wildfly/ >>>>>>> >>>>>>> Arun >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Apiman-user mailing list >>>>>> Apiman-user at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user >>>>>> >>>>> _______________________________________________ >>>>> Apiman-user mailing list >>>>> Apiman-user at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/apiman-user >>>> >>>> >>>> >>>> >>> >> >> >> > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user From arun.gupta at gmail.com Thu Jul 23 11:15:25 2015 From: arun.gupta at gmail.com (Arun Gupta) Date: Thu, 23 Jul 2015 09:15:25 -0600 Subject: [Apiman-user] Creating resources using Docker image In-Reply-To: <55B0ED51.2050804@redhat.com> References: <55B09C1F.4090300@gmail.com> <55B0D0C3.9060603@redhat.com> <55B0D3C9.3030400@redhat.com> <55B0ED51.2050804@redhat.com> Message-ID: If the container is started a fresh then it would not have any existing resources, isn't it? Otherwise the script will get into a nested loop to first check for organization, then service, then version, etc. Arun On Thu, Jul 23, 2015 at 7:34 AM, Eric Wittmann wrote: > I think it would be possible to have a run-once shell script. Either by > writing/checking some sort of "already run" file. Or else by querying > apiman to see if a particular entity exists. For example, query to see if > "My-Custom-Organization" exists ... if it does then skip the script. If > not, then run the multitude of curl commands to do what you want. > > -Eric > > On 7/23/2015 7:48 AM, Arun Gupta wrote: >> >> I've been thinking something on those lines. >> >> - Invoke shell script from Dockerfile >> - Start API Man >> - Run shell scripts >> - Shut it down >> - Go back to Dockerfile which will then start it >> >> Will share something, stay tuned. >> >> Arun >> >> On Thu, Jul 23, 2015 at 5:45 AM, Eric Wittmann >> wrote: >>> >>> You are probably more deft with docker than I am, but perhaps a shell >>> script >>> could be used to send a bunch of curl commands? >>> >>> -Eric >>> >>> On 7/23/2015 7:35 AM, Arun Gupta wrote: >>>> >>>> >>>> Thanks! >>>> >>>> What is the recommended design pattern to extend the Dockerfile in the >>>> meanwhile? >>>> >>>> Arun >>>> >>>> On Thu, Jul 23, 2015 at 5:32 AM, Eric Wittmann >>>> >>>> wrote: >>>>> >>>>> >>>>> That is not currently a feature. But I've now added a JIRA for it, >>>>> since it seems like a nice idea (especially for extending the docker >>>>> container). >>>>> >>>>> https://issues.jboss.org/browse/APIMAN-566 >>>>> >>>>> -Eric >>>>> >>>>> On 7/23/2015 3:47 AM, Tim Dudgeon wrote: >>>>>> >>>>>> >>>>>> This indeed would be very useful. >>>>>> Tim >>>>>> >>>>>> On 23/07/2015 04:44, Arun Gupta wrote: >>>>>>> >>>>>>> >>>>>>> I've created a Dockerfile [1] that will attempt to create different >>>>>>> resources. Is there any standard format where I can drop >>>>>>> .yml in a pre-defined directory and API Man will read >>>>>>> the resources defined there and create them? >>>>>>> >>>>>>> This will simplify how the resources are created using Docker. The >>>>>>> samples at [2] do not show that. >>>>>>> >>>>>>> [1] >>>>>>> >>>>>>> https://github.com/arun-gupta/microservices/blob/master/microservice/docker/Dockerfile >>>>>>> [2] https://registry.hub.docker.com/u/jboss/apiman-wildfly/ >>>>>>> >>>>>>> Arun >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Apiman-user mailing list >>>>>> Apiman-user at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user >>>>>> >>>>> _______________________________________________ >>>>> Apiman-user mailing list >>>>> Apiman-user at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/apiman-user >>>> >>>> >>>> >>>> >>>> >>> >> >> >> > -- http://blog.arungupta.me http://twitter.com/arungupta From eric.wittmann at redhat.com Thu Jul 23 11:57:10 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 23 Jul 2015 11:57:10 -0400 Subject: [Apiman-user] Creating resources using Docker image In-Reply-To: References: <55B09C1F.4090300@gmail.com> <55B0D0C3.9060603@redhat.com> <55B0D3C9.3030400@redhat.com> <55B0ED51.2050804@redhat.com> Message-ID: <55B10ED6.6010908@redhat.com> +1 - in production you would want separate docker containers for the API Manager vs. the API Gateway. We don't have these docker images/containers defined yet. As for scaling out the gateway - my suggestion for deployments is to have a single logical gateway made up of multiple identical (clustered) gateway docker containers. The gateway image would not have any bootstrapping to do. But each gateway container would connect to the same state-sharing server (e.g. elasticsearch or infinispan). Thus they all share registry info and rate limiting state, etc. It also means that a new gateway node can be spun up easily. -Eric On 7/23/2015 10:28 AM, Keith Babo wrote: > Interesting discussion. Another aspect to consider here is how the docker image will work with various deployment architectures. For the ?kick the tires? use case, I expect you will want all of apiman (admin server/console, gateway) and all of the configuration built into your image. Makes it really easy to get off and running with a known state. > > In the ?production? use case, I wonder if things will change a bit. In that scenario, I can see the need for separate images for the gateway and for the admin server/console. This would allow the gateway containers to scale up independent of the admin container. Does baking the config into the image make sense here? Maybe it does for initial configuration, but you?ll also need a way to pull configuration into new gateway containers as they scale up. > > cheers, > keith > >> On Jul 23, 2015, at 9:34 AM, Eric Wittmann wrote: >> >> I think it would be possible to have a run-once shell script. Either by >> writing/checking some sort of "already run" file. Or else by querying >> apiman to see if a particular entity exists. For example, query to see >> if "My-Custom-Organization" exists ... if it does then skip the script. >> If not, then run the multitude of curl commands to do what you want. >> >> -Eric >> >> On 7/23/2015 7:48 AM, Arun Gupta wrote: >>> I've been thinking something on those lines. >>> >>> - Invoke shell script from Dockerfile >>> - Start API Man >>> - Run shell scripts >>> - Shut it down >>> - Go back to Dockerfile which will then start it >>> >>> Will share something, stay tuned. >>> >>> Arun >>> >>> On Thu, Jul 23, 2015 at 5:45 AM, Eric Wittmann wrote: >>>> You are probably more deft with docker than I am, but perhaps a shell script >>>> could be used to send a bunch of curl commands? >>>> >>>> -Eric >>>> >>>> On 7/23/2015 7:35 AM, Arun Gupta wrote: >>>>> >>>>> Thanks! >>>>> >>>>> What is the recommended design pattern to extend the Dockerfile in the >>>>> meanwhile? >>>>> >>>>> Arun >>>>> >>>>> On Thu, Jul 23, 2015 at 5:32 AM, Eric Wittmann >>>>> wrote: >>>>>> >>>>>> That is not currently a feature. But I've now added a JIRA for it, >>>>>> since it seems like a nice idea (especially for extending the docker >>>>>> container). >>>>>> >>>>>> https://issues.jboss.org/browse/APIMAN-566 >>>>>> >>>>>> -Eric >>>>>> >>>>>> On 7/23/2015 3:47 AM, Tim Dudgeon wrote: >>>>>>> >>>>>>> This indeed would be very useful. >>>>>>> Tim >>>>>>> >>>>>>> On 23/07/2015 04:44, Arun Gupta wrote: >>>>>>>> >>>>>>>> I've created a Dockerfile [1] that will attempt to create different >>>>>>>> resources. Is there any standard format where I can drop >>>>>>>> .yml in a pre-defined directory and API Man will read >>>>>>>> the resources defined there and create them? >>>>>>>> >>>>>>>> This will simplify how the resources are created using Docker. The >>>>>>>> samples at [2] do not show that. >>>>>>>> >>>>>>>> [1] >>>>>>>> https://github.com/arun-gupta/microservices/blob/master/microservice/docker/Dockerfile >>>>>>>> [2] https://registry.hub.docker.com/u/jboss/apiman-wildfly/ >>>>>>>> >>>>>>>> Arun >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Apiman-user mailing list >>>>>>> Apiman-user at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user >>>>>>> >>>>>> _______________________________________________ >>>>>> Apiman-user mailing list >>>>>> Apiman-user at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> _______________________________________________ >> Apiman-user mailing list >> Apiman-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/apiman-user > From eric.wittmann at redhat.com Thu Jul 23 11:59:24 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 23 Jul 2015 11:59:24 -0400 Subject: [Apiman-user] Creating resources using Docker image In-Reply-To: References: <55B09C1F.4090300@gmail.com> <55B0D0C3.9060603@redhat.com> <55B0D3C9.3030400@redhat.com> <55B0ED51.2050804@redhat.com> Message-ID: <55B10F5C.8050204@redhat.com> I'm not sure what you mean by this. I'm only suggesting that the "bootstrap" script could first do a GET on *one* of the entities that the script is planning on creating. If the entity already exists then the script can bail at that point. I don't see how a loop is possible. And I don't think you would need to check for *each* entity you plan on creating. Just use the first entity as a marker - if *that* one exists then assume the rest do as well. On 7/23/2015 11:15 AM, Arun Gupta wrote: > If the container is started a fresh then it would not have any > existing resources, isn't it? > > Otherwise the script will get into a nested loop to first check for > organization, then service, then version, etc. > > Arun > > On Thu, Jul 23, 2015 at 7:34 AM, Eric Wittmann wrote: >> I think it would be possible to have a run-once shell script. Either by >> writing/checking some sort of "already run" file. Or else by querying >> apiman to see if a particular entity exists. For example, query to see if >> "My-Custom-Organization" exists ... if it does then skip the script. If >> not, then run the multitude of curl commands to do what you want. >> >> -Eric >> >> On 7/23/2015 7:48 AM, Arun Gupta wrote: >>> >>> I've been thinking something on those lines. >>> >>> - Invoke shell script from Dockerfile >>> - Start API Man >>> - Run shell scripts >>> - Shut it down >>> - Go back to Dockerfile which will then start it >>> >>> Will share something, stay tuned. >>> >>> Arun >>> >>> On Thu, Jul 23, 2015 at 5:45 AM, Eric Wittmann >>> wrote: >>>> >>>> You are probably more deft with docker than I am, but perhaps a shell >>>> script >>>> could be used to send a bunch of curl commands? >>>> >>>> -Eric >>>> >>>> On 7/23/2015 7:35 AM, Arun Gupta wrote: >>>>> >>>>> >>>>> Thanks! >>>>> >>>>> What is the recommended design pattern to extend the Dockerfile in the >>>>> meanwhile? >>>>> >>>>> Arun >>>>> >>>>> On Thu, Jul 23, 2015 at 5:32 AM, Eric Wittmann >>>>> >>>>> wrote: >>>>>> >>>>>> >>>>>> That is not currently a feature. But I've now added a JIRA for it, >>>>>> since it seems like a nice idea (especially for extending the docker >>>>>> container). >>>>>> >>>>>> https://issues.jboss.org/browse/APIMAN-566 >>>>>> >>>>>> -Eric >>>>>> >>>>>> On 7/23/2015 3:47 AM, Tim Dudgeon wrote: >>>>>>> >>>>>>> >>>>>>> This indeed would be very useful. >>>>>>> Tim >>>>>>> >>>>>>> On 23/07/2015 04:44, Arun Gupta wrote: >>>>>>>> >>>>>>>> >>>>>>>> I've created a Dockerfile [1] that will attempt to create different >>>>>>>> resources. Is there any standard format where I can drop >>>>>>>> .yml in a pre-defined directory and API Man will read >>>>>>>> the resources defined there and create them? >>>>>>>> >>>>>>>> This will simplify how the resources are created using Docker. The >>>>>>>> samples at [2] do not show that. >>>>>>>> >>>>>>>> [1] >>>>>>>> >>>>>>>> https://github.com/arun-gupta/microservices/blob/master/microservice/docker/Dockerfile >>>>>>>> [2] https://registry.hub.docker.com/u/jboss/apiman-wildfly/ >>>>>>>> >>>>>>>> Arun >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Apiman-user mailing list >>>>>>> Apiman-user at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user >>>>>>> >>>>>> _______________________________________________ >>>>>> Apiman-user mailing list >>>>>> Apiman-user at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> > > > From arun.gupta at gmail.com Thu Jul 23 12:26:04 2015 From: arun.gupta at gmail.com (Arun Gupta) Date: Thu, 23 Jul 2015 10:26:04 -0600 Subject: [Apiman-user] Creating resources using Docker image In-Reply-To: <55B10F5C.8050204@redhat.com> References: <55B09C1F.4090300@gmail.com> <55B0D0C3.9060603@redhat.com> <55B0D3C9.3030400@redhat.com> <55B0ED51.2050804@redhat.com> <55B10F5C.8050204@redhat.com> Message-ID: That could work too! I was just trying to be comprehensive but YAGNI! Either way, as the state of the container is not preserved and a new container is started every time, what is the likelihood that the entity to be created will exist? Arun On Thu, Jul 23, 2015 at 9:59 AM, Eric Wittmann wrote: > I'm not sure what you mean by this. I'm only suggesting that the > "bootstrap" script could first do a GET on *one* of the entities that the > script is planning on creating. If the entity already exists then the > script can bail at that point. I don't see how a loop is possible. And I > don't think you would need to check for *each* entity you plan on creating. > Just use the first entity as a marker - if *that* one exists then assume the > rest do as well. > > On 7/23/2015 11:15 AM, Arun Gupta wrote: >> >> If the container is started a fresh then it would not have any >> existing resources, isn't it? >> >> Otherwise the script will get into a nested loop to first check for >> organization, then service, then version, etc. >> >> Arun >> >> On Thu, Jul 23, 2015 at 7:34 AM, Eric Wittmann >> wrote: >>> >>> I think it would be possible to have a run-once shell script. Either by >>> writing/checking some sort of "already run" file. Or else by querying >>> apiman to see if a particular entity exists. For example, query to see >>> if >>> "My-Custom-Organization" exists ... if it does then skip the script. If >>> not, then run the multitude of curl commands to do what you want. >>> >>> -Eric >>> >>> On 7/23/2015 7:48 AM, Arun Gupta wrote: >>>> >>>> >>>> I've been thinking something on those lines. >>>> >>>> - Invoke shell script from Dockerfile >>>> - Start API Man >>>> - Run shell scripts >>>> - Shut it down >>>> - Go back to Dockerfile which will then start it >>>> >>>> Will share something, stay tuned. >>>> >>>> Arun >>>> >>>> On Thu, Jul 23, 2015 at 5:45 AM, Eric Wittmann >>>> >>>> wrote: >>>>> >>>>> >>>>> You are probably more deft with docker than I am, but perhaps a shell >>>>> script >>>>> could be used to send a bunch of curl commands? >>>>> >>>>> -Eric >>>>> >>>>> On 7/23/2015 7:35 AM, Arun Gupta wrote: >>>>>> >>>>>> >>>>>> >>>>>> Thanks! >>>>>> >>>>>> What is the recommended design pattern to extend the Dockerfile in the >>>>>> meanwhile? >>>>>> >>>>>> Arun >>>>>> >>>>>> On Thu, Jul 23, 2015 at 5:32 AM, Eric Wittmann >>>>>> >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> That is not currently a feature. But I've now added a JIRA for it, >>>>>>> since it seems like a nice idea (especially for extending the docker >>>>>>> container). >>>>>>> >>>>>>> https://issues.jboss.org/browse/APIMAN-566 >>>>>>> >>>>>>> -Eric >>>>>>> >>>>>>> On 7/23/2015 3:47 AM, Tim Dudgeon wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This indeed would be very useful. >>>>>>>> Tim >>>>>>>> >>>>>>>> On 23/07/2015 04:44, Arun Gupta wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I've created a Dockerfile [1] that will attempt to create different >>>>>>>>> resources. Is there any standard format where I can drop >>>>>>>>> .yml in a pre-defined directory and API Man will read >>>>>>>>> the resources defined there and create them? >>>>>>>>> >>>>>>>>> This will simplify how the resources are created using Docker. The >>>>>>>>> samples at [2] do not show that. >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> >>>>>>>>> >>>>>>>>> https://github.com/arun-gupta/microservices/blob/master/microservice/docker/Dockerfile >>>>>>>>> [2] https://registry.hub.docker.com/u/jboss/apiman-wildfly/ >>>>>>>>> >>>>>>>>> Arun >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Apiman-user mailing list >>>>>>>> Apiman-user at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Apiman-user mailing list >>>>>>> Apiman-user at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >> >> >> > -- http://blog.arungupta.me http://twitter.com/arungupta From eric.wittmann at redhat.com Thu Jul 23 12:45:52 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 23 Jul 2015 12:45:52 -0400 Subject: [Apiman-user] Creating resources using Docker image In-Reply-To: References: <55B09C1F.4090300@gmail.com> <55B0D0C3.9060603@redhat.com> <55B0D3C9.3030400@redhat.com> <55B0ED51.2050804@redhat.com> <55B10F5C.8050204@redhat.com> Message-ID: <55B11A40.6090201@redhat.com> Is that true? The state of the container is lost each time you stop it? I thought the EAP data directory was preserved across container start/stop, so that the state was preserved. But I guess I'm wrong? If it's true that state is *not* preserved, then the script can just blindly run I guess. -Eric On 7/23/2015 12:26 PM, Arun Gupta wrote: > That could work too! I was just trying to be comprehensive but YAGNI! > > Either way, as the state of the container is not preserved and a new > container is started every time, what is the likelihood that the > entity to be created will exist? > > Arun > > On Thu, Jul 23, 2015 at 9:59 AM, Eric Wittmann wrote: >> I'm not sure what you mean by this. I'm only suggesting that the >> "bootstrap" script could first do a GET on *one* of the entities that the >> script is planning on creating. If the entity already exists then the >> script can bail at that point. I don't see how a loop is possible. And I >> don't think you would need to check for *each* entity you plan on creating. >> Just use the first entity as a marker - if *that* one exists then assume the >> rest do as well. >> >> On 7/23/2015 11:15 AM, Arun Gupta wrote: >>> >>> If the container is started a fresh then it would not have any >>> existing resources, isn't it? >>> >>> Otherwise the script will get into a nested loop to first check for >>> organization, then service, then version, etc. >>> >>> Arun >>> >>> On Thu, Jul 23, 2015 at 7:34 AM, Eric Wittmann >>> wrote: >>>> >>>> I think it would be possible to have a run-once shell script. Either by >>>> writing/checking some sort of "already run" file. Or else by querying >>>> apiman to see if a particular entity exists. For example, query to see >>>> if >>>> "My-Custom-Organization" exists ... if it does then skip the script. If >>>> not, then run the multitude of curl commands to do what you want. >>>> >>>> -Eric >>>> >>>> On 7/23/2015 7:48 AM, Arun Gupta wrote: >>>>> >>>>> >>>>> I've been thinking something on those lines. >>>>> >>>>> - Invoke shell script from Dockerfile >>>>> - Start API Man >>>>> - Run shell scripts >>>>> - Shut it down >>>>> - Go back to Dockerfile which will then start it >>>>> >>>>> Will share something, stay tuned. >>>>> >>>>> Arun >>>>> >>>>> On Thu, Jul 23, 2015 at 5:45 AM, Eric Wittmann >>>>> >>>>> wrote: >>>>>> >>>>>> >>>>>> You are probably more deft with docker than I am, but perhaps a shell >>>>>> script >>>>>> could be used to send a bunch of curl commands? >>>>>> >>>>>> -Eric >>>>>> >>>>>> On 7/23/2015 7:35 AM, Arun Gupta wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> What is the recommended design pattern to extend the Dockerfile in the >>>>>>> meanwhile? >>>>>>> >>>>>>> Arun >>>>>>> >>>>>>> On Thu, Jul 23, 2015 at 5:32 AM, Eric Wittmann >>>>>>> >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> That is not currently a feature. But I've now added a JIRA for it, >>>>>>>> since it seems like a nice idea (especially for extending the docker >>>>>>>> container). >>>>>>>> >>>>>>>> https://issues.jboss.org/browse/APIMAN-566 >>>>>>>> >>>>>>>> -Eric >>>>>>>> >>>>>>>> On 7/23/2015 3:47 AM, Tim Dudgeon wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> This indeed would be very useful. >>>>>>>>> Tim >>>>>>>>> >>>>>>>>> On 23/07/2015 04:44, Arun Gupta wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I've created a Dockerfile [1] that will attempt to create different >>>>>>>>>> resources. Is there any standard format where I can drop >>>>>>>>>> .yml in a pre-defined directory and API Man will read >>>>>>>>>> the resources defined there and create them? >>>>>>>>>> >>>>>>>>>> This will simplify how the resources are created using Docker. The >>>>>>>>>> samples at [2] do not show that. >>>>>>>>>> >>>>>>>>>> [1] >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://github.com/arun-gupta/microservices/blob/master/microservice/docker/Dockerfile >>>>>>>>>> [2] https://registry.hub.docker.com/u/jboss/apiman-wildfly/ >>>>>>>>>> >>>>>>>>>> Arun >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Apiman-user mailing list >>>>>>>>> Apiman-user at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Apiman-user mailing list >>>>>>>> Apiman-user at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> > > > From arun.gupta at gmail.com Thu Jul 23 12:57:14 2015 From: arun.gupta at gmail.com (Arun Gupta) Date: Thu, 23 Jul 2015 10:57:14 -0600 Subject: [Apiman-user] Creating resources using Docker image In-Reply-To: <55B11A40.6090201@redhat.com> References: <55B09C1F.4090300@gmail.com> <55B0D0C3.9060603@redhat.com> <55B0D3C9.3030400@redhat.com> <55B0ED51.2050804@redhat.com> <55B10F5C.8050204@redhat.com> <55B11A40.6090201@redhat.com> Message-ID: Start/stop yes, but not if the container is removed. And because the "cost" associated with restarting a container is low, restarting is more common that start/stop. Arun On Thu, Jul 23, 2015 at 10:45 AM, Eric Wittmann wrote: > Is that true? The state of the container is lost each time you stop it? I > thought the EAP data directory was preserved across container start/stop, so > that the state was preserved. But I guess I'm wrong? > > If it's true that state is *not* preserved, then the script can just blindly > run I guess. > > -Eric > > On 7/23/2015 12:26 PM, Arun Gupta wrote: >> >> That could work too! I was just trying to be comprehensive but YAGNI! >> >> Either way, as the state of the container is not preserved and a new >> container is started every time, what is the likelihood that the >> entity to be created will exist? >> >> Arun >> >> On Thu, Jul 23, 2015 at 9:59 AM, Eric Wittmann >> wrote: >>> >>> I'm not sure what you mean by this. I'm only suggesting that the >>> "bootstrap" script could first do a GET on *one* of the entities that the >>> script is planning on creating. If the entity already exists then the >>> script can bail at that point. I don't see how a loop is possible. And >>> I >>> don't think you would need to check for *each* entity you plan on >>> creating. >>> Just use the first entity as a marker - if *that* one exists then assume >>> the >>> rest do as well. >>> >>> On 7/23/2015 11:15 AM, Arun Gupta wrote: >>>> >>>> >>>> If the container is started a fresh then it would not have any >>>> existing resources, isn't it? >>>> >>>> Otherwise the script will get into a nested loop to first check for >>>> organization, then service, then version, etc. >>>> >>>> Arun >>>> >>>> On Thu, Jul 23, 2015 at 7:34 AM, Eric Wittmann >>>> >>>> wrote: >>>>> >>>>> >>>>> I think it would be possible to have a run-once shell script. Either >>>>> by >>>>> writing/checking some sort of "already run" file. Or else by querying >>>>> apiman to see if a particular entity exists. For example, query to see >>>>> if >>>>> "My-Custom-Organization" exists ... if it does then skip the script. >>>>> If >>>>> not, then run the multitude of curl commands to do what you want. >>>>> >>>>> -Eric >>>>> >>>>> On 7/23/2015 7:48 AM, Arun Gupta wrote: >>>>>> >>>>>> >>>>>> >>>>>> I've been thinking something on those lines. >>>>>> >>>>>> - Invoke shell script from Dockerfile >>>>>> - Start API Man >>>>>> - Run shell scripts >>>>>> - Shut it down >>>>>> - Go back to Dockerfile which will then start it >>>>>> >>>>>> Will share something, stay tuned. >>>>>> >>>>>> Arun >>>>>> >>>>>> On Thu, Jul 23, 2015 at 5:45 AM, Eric Wittmann >>>>>> >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> You are probably more deft with docker than I am, but perhaps a shell >>>>>>> script >>>>>>> could be used to send a bunch of curl commands? >>>>>>> >>>>>>> -Eric >>>>>>> >>>>>>> On 7/23/2015 7:35 AM, Arun Gupta wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> What is the recommended design pattern to extend the Dockerfile in >>>>>>>> the >>>>>>>> meanwhile? >>>>>>>> >>>>>>>> Arun >>>>>>>> >>>>>>>> On Thu, Jul 23, 2015 at 5:32 AM, Eric Wittmann >>>>>>>> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> That is not currently a feature. But I've now added a JIRA for it, >>>>>>>>> since it seems like a nice idea (especially for extending the >>>>>>>>> docker >>>>>>>>> container). >>>>>>>>> >>>>>>>>> https://issues.jboss.org/browse/APIMAN-566 >>>>>>>>> >>>>>>>>> -Eric >>>>>>>>> >>>>>>>>> On 7/23/2015 3:47 AM, Tim Dudgeon wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This indeed would be very useful. >>>>>>>>>> Tim >>>>>>>>>> >>>>>>>>>> On 23/07/2015 04:44, Arun Gupta wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I've created a Dockerfile [1] that will attempt to create >>>>>>>>>>> different >>>>>>>>>>> resources. Is there any standard format where I can drop >>>>>>>>>>> .yml in a pre-defined directory and API Man will >>>>>>>>>>> read >>>>>>>>>>> the resources defined there and create them? >>>>>>>>>>> >>>>>>>>>>> This will simplify how the resources are created using Docker. >>>>>>>>>>> The >>>>>>>>>>> samples at [2] do not show that. >>>>>>>>>>> >>>>>>>>>>> [1] >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://github.com/arun-gupta/microservices/blob/master/microservice/docker/Dockerfile >>>>>>>>>>> [2] https://registry.hub.docker.com/u/jboss/apiman-wildfly/ >>>>>>>>>>> >>>>>>>>>>> Arun >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Apiman-user mailing list >>>>>>>>>> Apiman-user at lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Apiman-user mailing list >>>>>>>>> Apiman-user at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >> >> >> > -- http://blog.arungupta.me http://twitter.com/arungupta From jorgemoralespou at gmail.com Mon Jul 27 05:44:24 2015 From: jorgemoralespou at gmail.com (Jorge Morales Pou) Date: Mon, 27 Jul 2015 11:44:24 +0200 Subject: [Apiman-user] Creating resources using Docker image In-Reply-To: <55B10ED6.6010908@redhat.com> References: <55B09C1F.4090300@gmail.com> <55B0D0C3.9060603@redhat.com> <55B0D3C9.3030400@redhat.com> <55B0ED51.2050804@redhat.com> <55B10ED6.6010908@redhat.com> Message-ID: And do not forget that etcd is the registry used in OpenShift, so can be convenient to think in using as state-sharing server etcd as well. 2015-07-23 17:57 GMT+02:00 Eric Wittmann : > +1 - in production you would want separate docker containers for the API > Manager vs. the API Gateway. We don't have these docker > images/containers defined yet. > > As for scaling out the gateway - my suggestion for deployments is to > have a single logical gateway made up of multiple identical (clustered) > gateway docker containers. The gateway image would not have any > bootstrapping to do. But each gateway container would connect to the > same state-sharing server (e.g. elasticsearch or infinispan). Thus they > all share registry info and rate limiting state, etc. It also means > that a new gateway node can be spun up easily. > > -Eric > > On 7/23/2015 10:28 AM, Keith Babo wrote: > > Interesting discussion. Another aspect to consider here is how the > docker image will work with various deployment architectures. For the > ?kick the tires? use case, I expect you will want all of apiman (admin > server/console, gateway) and all of the configuration built into your > image. Makes it really easy to get off and running with a known state. > > > > In the ?production? use case, I wonder if things will change a bit. In > that scenario, I can see the need for separate images for the gateway and > for the admin server/console. This would allow the gateway containers to > scale up independent of the admin container. Does baking the config into > the image make sense here? Maybe it does for initial configuration, but > you?ll also need a way to pull configuration into new gateway containers as > they scale up. > > > > cheers, > > keith > > > >> On Jul 23, 2015, at 9:34 AM, Eric Wittmann > wrote: > >> > >> I think it would be possible to have a run-once shell script. Either by > >> writing/checking some sort of "already run" file. Or else by querying > >> apiman to see if a particular entity exists. For example, query to see > >> if "My-Custom-Organization" exists ... if it does then skip the script. > >> If not, then run the multitude of curl commands to do what you want. > >> > >> -Eric > >> > >> On 7/23/2015 7:48 AM, Arun Gupta wrote: > >>> I've been thinking something on those lines. > >>> > >>> - Invoke shell script from Dockerfile > >>> - Start API Man > >>> - Run shell scripts > >>> - Shut it down > >>> - Go back to Dockerfile which will then start it > >>> > >>> Will share something, stay tuned. > >>> > >>> Arun > >>> > >>> On Thu, Jul 23, 2015 at 5:45 AM, Eric Wittmann < > eric.wittmann at redhat.com> wrote: > >>>> You are probably more deft with docker than I am, but perhaps a shell > script > >>>> could be used to send a bunch of curl commands? > >>>> > >>>> -Eric > >>>> > >>>> On 7/23/2015 7:35 AM, Arun Gupta wrote: > >>>>> > >>>>> Thanks! > >>>>> > >>>>> What is the recommended design pattern to extend the Dockerfile in > the > >>>>> meanwhile? > >>>>> > >>>>> Arun > >>>>> > >>>>> On Thu, Jul 23, 2015 at 5:32 AM, Eric Wittmann < > eric.wittmann at redhat.com> > >>>>> wrote: > >>>>>> > >>>>>> That is not currently a feature. But I've now added a JIRA for it, > >>>>>> since it seems like a nice idea (especially for extending the docker > >>>>>> container). > >>>>>> > >>>>>> https://issues.jboss.org/browse/APIMAN-566 > >>>>>> > >>>>>> -Eric > >>>>>> > >>>>>> On 7/23/2015 3:47 AM, Tim Dudgeon wrote: > >>>>>>> > >>>>>>> This indeed would be very useful. > >>>>>>> Tim > >>>>>>> > >>>>>>> On 23/07/2015 04:44, Arun Gupta wrote: > >>>>>>>> > >>>>>>>> I've created a Dockerfile [1] that will attempt to create > different > >>>>>>>> resources. Is there any standard format where I can drop > >>>>>>>> .yml in a pre-defined directory and API Man will > read > >>>>>>>> the resources defined there and create them? > >>>>>>>> > >>>>>>>> This will simplify how the resources are created using Docker. The > >>>>>>>> samples at [2] do not show that. > >>>>>>>> > >>>>>>>> [1] > >>>>>>>> > https://github.com/arun-gupta/microservices/blob/master/microservice/docker/Dockerfile > >>>>>>>> [2] https://registry.hub.docker.com/u/jboss/apiman-wildfly/ > >>>>>>>> > >>>>>>>> Arun > >>>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Apiman-user mailing list > >>>>>>> Apiman-user at lists.jboss.org > >>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> Apiman-user mailing list > >>>>>> Apiman-user at lists.jboss.org > >>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>> > >>> > >>> > >> _______________________________________________ > >> Apiman-user mailing list > >> Apiman-user at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/apiman-user > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20150727/9808f737/attachment.html