Re: [Architecture] RFC: RESTFul API for API Manager

Hi Joe, Please find my comments inline. The reason to separate the Impl classes and the API beans are so that we > can regenerate the API beans repeatedly. I am totally +1 for *separating* Impl classes and the API beans. My suggestion is that I think we need to consider on managing these Impl cl

Re: [Architecture] RFC: RESTFul API for API Manager

Hi Rasika The reason to separate the Impl classes and the API beans are so that we can regenerate the API beans repeatedly. This will allow us to bring in the changes that we do to the API Definition in to the Implementation quite easily just by regenerating the code. What are the specific use ca

Re: [Architecture] RFC: RESTFul API for API Manager

Hi Malintha, Thanks for the clarification. Further analyzing I found that "swagger code generator" maven plugin[1] is using "swagger-codegen" library[2] to generate these CXF classes. But "swagger-codegen" library does not include spring framework support natively, instead it uses its own Factory

Re: [Architecture] RFC: RESTFul API for API Manager

Hi Rasika, These set of classes are actually generated code (please see "gen" part of paths). We are using a code generator [1] to generate CXF server code skeleton from the swagger definition for store [2] and publisher. So there is no maintenance overhead. IMO by doing that way we can clearly s

Re: [Architecture] RFC: RESTFul API for API Manager

Hi All, I was going through the RESTfull API implementation which is very rich set of APIs. I'm just trying to understand why we are using the Factory pattern here. For instance; we are using "three" java classes for "Applications" API namely ApplicationsAPIServiceFactory[1], ApplicationsAPI[2] a

Re: [Architecture] RFC: RESTFul API for API Manager

With regard to the "search" APIs, we need to return an HTTP 204 for searches which do not return anything. Thanks, NuwanD. On Wed, Apr 22, 2015 at 8:11 PM, Sanjeewa Malalgoda wrote: > Hi All, > I did some research about applying security for the rest API we developed > so far. > Seems we have f

Re: [Architecture] RFC: RESTFul API for API Manager

Hi All, I did some research about applying security for the rest API we developed so far. Seems we have following options. Please add your suggestions as well. - Basic Oauth - Oauth 1.0 and 2.0. - SSL with client certificates - XACML plocy based security mechanism It seems oauth 2.0 a

Re: [Architecture] RFC: RESTFul API for API Manager

You can find the diff of the changes here [2] [2] https://github.com/hevayo/restful-apim/commit/ace429f3f4f2c62c36c5b4d55e9637c5db24b2ae On Fri, Apr 3, 2015 at 12:56 PM, Joseph Fonseka wrote: > Hi All > >

Re: [Architecture] RFC: RESTFul API for API Manager

Hi All Please find the latest API definition @ [1] with the following changes. 1. All the resources are updated with the relevant HTTP headers and responses proposed by Frank. 2. Added search condition grammar for API search. 3. Added next page and previo

Re: [Architecture] RFC: RESTFul API for API Manager

Hi Jo, Here i have attached updated apim.yaml file with my suggestions. Lets merge that to latest code. Thanks, sanjeewa. On Wed, Apr 1, 2015 at 1:55 PM, Sanjeewa Malalgoda wrote: > Hi All, > > Here are my suggestions on this implementation. > When we design rest API for API Management function

Re: [Architecture] RFC: RESTFul API for API Manager

Cool.. thanks Frank. On Wed, Apr 1, 2015 at 4:58 PM, Frank Leymann wrote: > Hi Nirmal, > > camel case should not be used because: > >- the domain name (aka host) is not case sensitive by definition, >- some servers treat the path not as case sensitive > > thus, camel case style will be c

Re: [Architecture] RFC: RESTFul API for API Manager

Hi Nirmal, camel case should not be used because: - the domain name (aka host) is not case sensitive by definition, - some servers treat the path not as case sensitive thus, camel case style will be confusing, implying differences in API names that don't exist. Nevertheless, a couple of ve

Re: [Architecture] RFC: RESTFul API for API Manager

This is very helpful Frank, and as you mentioned these controlled-resources are always lead to discussion. Do you have any comments on the usage of '-' instead of camel case ? On Tue, Mar 31, 2015 at 10:51 PM, Frank Leymann wrote: > Hi Jo, hi Manu, > > how to cope with "actions" that cannot be m

Re: [Architecture] RFC: RESTFul API for API Manager

Hi All, Here are my suggestions on this implementation. When we design rest API for API Management functionality we need to focus bit on publisher/ store aspects as well. Or we may need to have control at some point based on the logged in user. Here is one example: /apis GET /apis API provider sh

Re: [Architecture] RFC: RESTFul API for API Manager

Hi Frank Yes 2pm is fine for me, my skype is "jpfonseka". Will ask "Sanjeewa Malalgoda" to join as well he was working on the ground work for the implementation. Thanks & Regards Jo On Tue, Mar 31, 2015 at 5:03 PM, Frank Leymann wrote: > Hi Jo, > > is it possible for you to have a call tomo

Re: [Architecture] RFC: RESTFul API for API Manager

Hi Jo, hi Manu, how to cope with "actions" that cannot be mapped onto the CRUD methods on individual resources or collection resources is always a matter of discussion and taste when designing REST interfaces. A very often used guideline is to use so-called *controller resources*. I controller re

Re: [Architecture] RFC: RESTFul API for API Manager

Hi Jo, is it possible for you to have a call tomorrow, Wednesday, 4/1, 2pm Colombo time (i.e. 10:30am Germany, daylight-savings-time). I thing a 30...60 minutes will be suffice. Main purpose would be how to proceed :-) I find Skype more reliable than Hangouts. Would you mind about a Skype call?

Re: [Architecture] RFC: RESTFul API for API Manager

Hi Manu Copy API will duplicate not just the resource it will duplicate all the resources associated to it as well eg. Documents. So re-posting the API resource json will not be sufficient in this particular case. But there is a possibility of duplicating the associated resources from the client a

Re: [Architecture] RFC: RESTFul API for API Manager

Hi Frank, I see few endpoints representing actions rather than resources. For example POST /apis/{apiId}/copy-api. This is an action because there is no resource called copy-api. I would rather see it as posting an existing API to the /apis. In a HATEOS system we will be posting the href of an exis

Re: [Architecture] RFC: RESTFul API for API Manager

Hi Frank Thanks for the feedback. And it is nice to see how we can control cashing and concurrency with the additional headers. We will update the remaining APIs with the same concepts. Please let us know a convenient time for a call to discuss on it further. Also we will try to document these d

Re: [Architecture] RFC: RESTFul API for API Manager

Hi Jo, again, thanks for your work: we'll get a nice RESTful API :-) In the Richardson maturity model we'll get to level 2 (not level 3 because we are leaving out HATEOS - which is something that is not used often today in practice anyhow). I exported the YAML of the API, put it into a Word doc

Re: [Architecture] RFC: RESTFul API for API Manager

Hi Jo, I'll provide my input until Sunday evening... Best regards, Frank 2015-03-26 4:52 GMT+01:00 Joseph Fonseka : > Hi Frank > > What are the headers we should include ? > > 1. For the access token header we can define it globally in the security > definition [1] >

Re: [Architecture] RFC: RESTFul API for API Manager

Hi Frank What are the headers we should include ? 1. For the access token header we can define it globally in the security definition [1] 2. Content-type headers are covered by the consumes and pro

Re: [Architecture] RFC: RESTFul API for API Manager

Hi Jo, nice piece of work! What is still needed is a description of the header fields for both, the requests and APIs. Best regards, Frank 2015-03-24 17:34 GMT+01:00 Joseph Fonseka : > Hi All > > We are planing to implement a RESTFul API to expose the API Manager > functionality. This will b

[Architecture] RFC: RESTFul API for API Manager

Hi All We are planing to implement a RESTFul API to expose the API Manager functionality. This will be a replacement to the currently provided Store and Publisher APIs [1] & [2] . Main Motivation.