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
classes like the API wrapper classes(if we are using spring framework).
What are the specific use cases that you want to achieve using spring
> framework bean scopes ? As of now all the API beans have singleton scope
> since its the default.
Yeah that's true. But this will come in to play for any other use case
apart from the *default* use case. IMO, the problem of the current approach
is that,
we are
*
not
*
using spring framework efficiently.
How about using @Resource[1] for the Impl classes without Factories? I
think it might work.
*ApplicationsApi.java*
*-------------------------*
@Path("/applications")
@Consumes({ "application/json" })
@Produces({ "application/json" })
@io.swagger.annotations.Api(value = "/applications", description = "the
applications API")
public class ApplicationsApi {
*@Resource(name="applicationApiBean")*
private ApplicationsApiService delegate;
}
WEB-INF/beans.xml
------------------------
<beans xmlns="http://www.springframework.org/schema/beans"; xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance";
xmlns:jaxrs="http://cxf.apache.org/jaxrs"; xmlns:context="
http://www.springframework.org/schema/context";
xmlns:cxf="http://cxf.apache.org/core";
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-3.0.xsd
http://cxf.apache.org/jaxrs http://cxf.apache.org/schemas/jaxrs.xsd
http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd";>
<bean id="*applicationApiBean*" class="
*org.wso2.carbon.apimgt.rest.api.store.impl.ApplicationsApiServiceImpl*"/>
</beans>
[1] http://www.concretepage.com/spring/resource_annotation_spring
Thanks you,
Rasika
On Thu, Nov 12, 2015 at 8:37 AM, Joseph Fonseka <jos...@wso2.com> wrote:
> 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 cases that you want to achieve using spring
> framework bean scopes ? As of now all the API beans have singleton scope
> since its the default.
>
> Regards
> Jo
>
> On Wed, Nov 11, 2015 at 5:19 PM, Rasika Perera <rasi...@wso2.com> wrote:
>
>> 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
>> Method to manage beans initialization. Support for the "spring
>> framework" is introduced on "swagger code generator" maven plugin[3].
>>
>> Swagger Definition --> Swagger2CXF Maven Plugin --> Swagger Codegen
>> Library
>>
>> (beans.xml) (factory method)
>>
>> IMO according to current approach, actually we are managing the
>> "beans-wrapper" instead of the real API bean. For instance, we specify
>> "org.wso2.carbon.apimgt.rest.api.store.TagsApi"
>> on the "beans.xml"[4] and "TagsApi" will be managed by the spring
>> framework.
>>
>> No matter how many instances of the "TagsApi" will be scaled up by spring
>> framework; we are still pointing to one singleton "TagsApiServiceImpl"
>> class[4]. My argument is we really need to let the spring framework managed
>> the API bean i.e. "TagsApiServiceImpl".
>>
>> Thank you
>>
>> [1] https://github.com/hevayo/swagger2cxf-maven-plugin
>> [2]
>> https://github.com/swagger-api/swagger-codegen/blob/master/modules/swagger-codegen/src/main/java/io/swagger/codegen/languages/JaxRSServerCodegen.java
>> [3]
>> https://github.com/hevayo/swagger2cxf-maven-plugin/blob/master/src/main/java/org/wso2/maven/plugins/CxfCodeGen.java#L68
>> [4]
>> https://github.com/wso2/carbon-apimgt/blob/release-1.10.x/components/apimgt/org.wso2.carbon.apimgt.rest.api.store/src/gen/java/org/wso2/carbon/apimgt/rest/api/store/factories/TagsApiServiceFactory.java#L8
>>
>> On Fri, Nov 6, 2015 at 11:47 AM, Malintha Amarasinghe <malint...@wso2.com
>> > wrote:
>>
>>> 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 separate CXF infrastructure related
>>> code (annotations etc) and our implementation logic which makes the code
>>> clean and easy to read.
>>>
>>> Thanks
>>> Malintha
>>>
>>> [1] https://github.com/hevayo/swagger2cxf-maven-plugin
>>> [2]
>>> https://github.com/wso2/carbon-apimgt/blob/release-1.10.x/components/apimgt/org.wso2.carbon.apimgt.rest.api.store/src/main/resources/store-api.yaml
>>>
>>>
>>> On Fri, Nov 6, 2015 at 11:00 AM, Rasika Perera <rasi...@wso2.com> wrote:
>>>
>>>> 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] and
>>>> ApplicationsAPIService[3]. IMO this looks redundant and makes it harder to
>>>> maintain. Can't we use only one POJO with JAX-RS annotations and let the
>>>> container/ spring framework manage the lifecycle and other properties of
>>>> the bean?
>>>>
>>>> We could also use additional parameters such as "scope=singleton" in
>>>> your beans.xml[4] as explained on [5].
>>>>
>>>> Thank you,
>>>> Rasika
>>>>
>>>> [1]
>>>> https://github.com/wso2/carbon-apimgt/blob/release-1.10.x/components/apimgt/org.wso2.carbon.apimgt.rest.api.store/src/gen/java/org/wso2/carbon/apimgt/rest/api/store/factories/ApplicationsApiServiceFactory.java
>>>> [2]
>>>> https://github.com/wso2/carbon-apimgt/blob/release-1.10.x/components/apimgt/org.wso2.carbon.apimgt.rest.api.store/src/gen/java/org/wso2/carbon/apimgt/rest/api/store/ApplicationsApi.java
>>>> [3]
>>>> https://github.com/wso2/carbon-apimgt/blob/release-1.10.x/components/apimgt/org.wso2.carbon.apimgt.rest.api.store/src/gen/java/org/wso2/carbon/apimgt/rest/api/store/ApplicationsApiService.java
>>>> [4]
>>>> https://github.com/wso2/carbon-apimgt/blob/release-1.10.x/components/apimgt/org.wso2.carbon.apimgt.rest.api.store/src/main/webapp/WEB-INF/beans.xml#L13
>>>> [5] http://www.tutorialspoint.com/spring/spring_bean_scopes.htm
>>>>
>>>> On Mon, Aug 24, 2015 at 3:08 PM, Nuwan Dias <nuw...@wso2.com> wrote:
>>>>
>>>>> 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 <sanje...@wso2.com
>>>>> > wrote:
>>>>>
>>>>>> 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 and basic authentication are widely used to
>>>>>> secure rest APIs.
>>>>>> XACML also would be good solution as we need to control user
>>>>>> operations based on their roles/privileges etc (as example, api consumer
>>>>>> is
>>>>>> not allowed to call delete API operation).
>>>>>>
>>>>>> Since we are developing jax-rs web application and we have CXF run
>>>>>> time in API Manager, i started this with cxf interceptor for our
>>>>>> rest application.
>>>>>> We can engage it in PRE_INVOKE phase to minimize additional
>>>>>> processing for unauthenticated requests.
>>>>>> If we plan to go for XACML based approach we may use same
>>>>>> interceptor as policy enforcement point with small modifications.
>>>>>>
>>>>>> If we go for XACML based approach i feel it will be easy to manage
>>>>>> permissions per resources.
>>>>>> If we move ahead with Oauth2.0 we may need to scopes to control fine
>>>>>> grained access to APIs.
>>>>>>
>>>>>> Didn't got time to look at certificate based approach. But in that
>>>>>> case also we have to control access to APIs somehow(using information on
>>>>>> certificate or some other way).
>>>>>>
>>>>>> Highly appreciate your suggestions to move forward with this.
>>>>>>
>>>>>> Thanks,
>>>>>> sanjeewa.
>>>>>>
>>>>>> On Fri, Apr 3, 2015 at 12:58 PM, Joseph Fonseka <jos...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>> You can find the diff of the changes here [2]
>>>>>>> <https://github.com/hevayo/restful-apim/commit/ace429f3f4f2c62c36c5b4d55e9637c5db24b2ae>
>>>>>>>
>>>>>>>
>>>>>>> [2]
>>>>>>> https://github.com/hevayo/restful-apim/commit/ace429f3f4f2c62c36c5b4d55e9637c5db24b2ae
>>>>>>>
>>>>>>> On Fri, Apr 3, 2015 at 12:56 PM, Joseph Fonseka <jos...@wso2.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi All
>>>>>>>>
>>>>>>>> Please find the latest API definition @ [1]
>>>>>>>> <http://hevayo.github.io/restful-apim/#/> 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 previous page for "List" models
>>>>>>>> 4. Added operational resource for updating tier permissions sent by
>>>>>>>> Sanjeewa.
>>>>>>>>
>>>>>>>> Some more issues to discuss
>>>>>>>> 1. Currently API Id is made from a composite key
>>>>>>>> including (name/version/provider). In the REST API we thought of
>>>>>>>> passing
>>>>>>>> the API ID as a concatenated string with the above 3 attributes
>>>>>>>> delimited
>>>>>>>> by a special character ( thinking of + ). Is there a better approach to
>>>>>>>> handle this ?
>>>>>>>>
>>>>>>>> 2. Should we come up with application specific error codes to
>>>>>>>> passed in Error objects. Following are the benefits.
>>>>>>>> - Same HTTP error code can be mapped to two different errors
>>>>>>>> (eg. in /apis/{apiId}/document/{documentId} can return 404 if either
>>>>>>>> api or
>>>>>>>> document missing )
>>>>>>>> - If client wants to localize errors he can do with error
>>>>>>>> codes.
>>>>>>>>
>>>>>>>> Please share your thoughts.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Jo
>>>>>>>>
>>>>>>>> [1] http://hevayo.github.io/restful-apim/#/
>>>>>>>>
>>>>>>>> On Wed, Apr 1, 2015 at 6:35 PM, Sanjeewa Malalgoda <
>>>>>>>> sanje...@wso2.com> wrote:
>>>>>>>>
>>>>>>>>> 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 <
>>>>>>>>> sanje...@wso2.com> wrote:
>>>>>>>>>
>>>>>>>>>> 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 should be mandatory field when it comes to publisher
>>>>>>>>>> context.
>>>>>>>>>> API consumer should be mandatory field when it comes to store
>>>>>>>>>> context.
>>>>>>>>>> Or we should be able to retrieve current user by using JWT comes
>>>>>>>>>> with request or from access token. Still need to if request comes to
>>>>>>>>>> store
>>>>>>>>>> or publisher context.
>>>>>>>>>>
>>>>>>>>>> And based on current user permissions we may need enable, disable
>>>>>>>>>> API add/modification via post, put, delete.
>>>>>>>>>>
>>>>>>>>>> Also for tiers we may have
>>>>>>>>>>
>>>>>>>>>> /tiers
>>>>>>>>>>
>>>>>>>>>> post
>>>>>>>>>> /tiers/{tierName}/update-permission
>>>>>>>>>>
>>>>>>>>>> Request body
>>>>>>>>>> {
>>>>>>>>>> "rolePermission": {
>>>>>>>>>> "access": "",
>>>>>>>>>> "roles": ""
>>>>>>>>>> }
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Also for apis/{apiId} PUT need to have response with 409 Conflict
>>>>>>>>>> as well. Normally when we update resource with some information it
>>>>>>>>>> cannot
>>>>>>>>>> be accessed due to some reason. So IMO having 409 as well would be
>>>>>>>>>> helpful(in addition to 412)
>>>>>>>>>>
>>>>>>>>>> It would be ideal /apis/{apiId}/change-lifecycle success response
>>>>>>>>>> returns 200 status code as we normally use 201 to indicate that new
>>>>>>>>>> resource created.
>>>>>>>>>> In this particular case we do update for existing resource state.
>>>>>>>>>>
>>>>>>>>>> We may include additional response code to
>>>>>>>>>> /apis/{apiId}/documents GET because we may have 2 situations.
>>>>>>>>>> 01. API does not exists(We can consider 412 for response code)
>>>>>>>>>> 02. API exists but documents not available(we can consider 404 as
>>>>>>>>>> requested resource is document).
>>>>>>>>>>
>>>>>>>>>> And same should apply to /apis/{apiId}/documents/{documentId} GET
>>>>>>>>>> as well.
>>>>>>>>>>
>>>>>>>>>> And we need to finalize about security model for this rest API.
>>>>>>>>>> For that we may consider few options.
>>>>>>>>>>
>>>>>>>>>> 01. Oath2 secured API.
>>>>>>>>>> 02. Basic auth secured rest API.
>>>>>>>>>> 03. Other security mechanisms.
>>>>>>>>>>
>>>>>>>>>> My personal opinion is this rest API should be independent from
>>>>>>>>>> security protocol.
>>>>>>>>>> And our rest API should not rely on any security related
>>>>>>>>>> information when in process request.
>>>>>>>>>> If we need to verify user is having permission to do some task
>>>>>>>>>> then we should not do it in rest API level(api subscriber should not
>>>>>>>>>> allow
>>>>>>>>>> to update API).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> sanjeewa.
>>>>>>>>>>
>>>>>>>>>> On Tue, Mar 31, 2015 at 11:07 PM, Joseph Fonseka <jos...@wso2.com
>>>>>>>>>> > wrote:
>>>>>>>>>>
>>>>>>>>>>> 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 <fr...@wso2.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> 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? My SkypeID is frank.leymann
>>>>>>>>>>>>
>>>>>>>>>>>> Talk to you then!
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>> Frank
>>>>>>>>>>>>
>>>>>>>>>>>> 2015-03-30 13:03 GMT+02:00 Joseph Fonseka <jos...@wso2.com>:
>>>>>>>>>>>>
>>>>>>>>>>>>> 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 design decisions and
>>>>>>>>>>>>> concepts to benefit APIs created in the future.
>>>>>>>>>>>>>
>>>>>>>>>>>>> BTW. The changes were pushed to the repo.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>> Jo
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1] http://hevayo.github.io/restful-apim/
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sat, Mar 28, 2015 at 12:47 AM, Frank Leymann <
>>>>>>>>>>>>> fr...@wso2.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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 document
>>>>>>>>>>>>>> and used the "change tracking" feature to comment/modify across
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> document - please find the document attached. (Frank Input - API
>>>>>>>>>>>>>> Manager
>>>>>>>>>>>>>> API - 2015-03-27.docx)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> All the changes I made to YAML itself is in the separate
>>>>>>>>>>>>>> swagger YAML file I attached too. I used the swagger 2.0 tool
>>>>>>>>>>>>>> to create
>>>>>>>>>>>>>> this YAML, and the tool shows no syntax errors... So you may
>>>>>>>>>>>>>> import it into
>>>>>>>>>>>>>> your tool without problems. (FL Input API Manager API -
>>>>>>>>>>>>>> 2015-03-27.yaml)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I worked on the apis of the /apis and /apis/{apiID}
>>>>>>>>>>>>>> resources. Before I continue, I suggest that we have a
>>>>>>>>>>>>>> discussion (i.e. a
>>>>>>>>>>>>>> call) to discuss the changes/suggestions I made. We need to
>>>>>>>>>>>>>> agree whether
>>>>>>>>>>>>>> this fits into the plan for implementing in the next release.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Looking forward....
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>> Frank
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2015-03-26 4:52 GMT+01:00 Joseph Fonseka <jos...@wso2.com>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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]
>>>>>>>>>>>>>>> <https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md#securityDefinitionsObject>
>>>>>>>>>>>>>>> 2. Content-type headers are covered by the consumes and
>>>>>>>>>>>>>>> produces attributes [2]
>>>>>>>>>>>>>>> <https://github.com/hevayo/restful-apim/blob/master/apim.yaml#L18-L19>
>>>>>>>>>>>>>>> 3. For post methods we have an option of sending "Link"
>>>>>>>>>>>>>>> header with a URL to newly created resource rather than
>>>>>>>>>>>>>>> returning newly
>>>>>>>>>>>>>>> created resource JSON.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>> Jo
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>> https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md#securityDefinitionsObject
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [2]
>>>>>>>>>>>>>>> https://github.com/hevayo/restful-apim/blob/master/apim.yaml#L18-L19
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wed, Mar 25, 2015 at 3:51 PM, Frank Leymann <
>>>>>>>>>>>>>>> fr...@wso2.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 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 <jos...@wso2.com>
>>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 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]
>>>>>>>>>>>>>>>>> <https://docs.wso2.com/display/AM180/Publisher+APIs> & [2]
>>>>>>>>>>>>>>>>> <https://docs.wso2.com/display/AM180/Store+APIs>.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Main Motivation.
>>>>>>>>>>>>>>>>> 1. The current APIs are not RESTful and they do not cover
>>>>>>>>>>>>>>>>> all the functionality.
>>>>>>>>>>>>>>>>> 2. To make it easy to integrate and automate API manager
>>>>>>>>>>>>>>>>> functionality with 3rd party systems.
>>>>>>>>>>>>>>>>> 3. To provide better security with Oauth.
>>>>>>>>>>>>>>>>> 4. To provide better versioning and documentation with the
>>>>>>>>>>>>>>>>> API.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> As a start we have written a draft version of the API
>>>>>>>>>>>>>>>>> definition which you can find here [3]
>>>>>>>>>>>>>>>>> <http://hevayo.github.io/restful-apim/>.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Following is a rough implementation plan.
>>>>>>>>>>>>>>>>> 1. Work on the API Definition, get feed back from users
>>>>>>>>>>>>>>>>> and finalize.
>>>>>>>>>>>>>>>>> 2. Implementation. ( Architecture , Jax-RS ?)
>>>>>>>>>>>>>>>>> 3. Adding Security. ( O-auth, scopes ? )
>>>>>>>>>>>>>>>>> 4. Testing.
>>>>>>>>>>>>>>>>> 5. Documentation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> API definition was written with Swagger 2 once completed
>>>>>>>>>>>>>>>>> we can use it to generate server stubs, client stubs and
>>>>>>>>>>>>>>>>> documentation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Please share your thoughts.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>> Jo
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> [1] https://docs.wso2.com/display/AM180/Publisher+APIs
>>>>>>>>>>>>>>>>> [2] https://docs.wso2.com/display/AM180/Store+APIs
>>>>>>>>>>>>>>>>> [3] http://hevayo.github.io/restful-apim/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> *Joseph Fonseka*
>>>>>>>>>>>>>>>>> WSO2 Inc.; http://wso2.com
>>>>>>>>>>>>>>>>> lean.enterprise.middleware
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> mobile: +94 772 512 430
>>>>>>>>>>>>>>>>> skype: jpfonseka
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> * <http://lk.linkedin.com/in/rumeshbandara>*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> *Joseph Fonseka*
>>>>>>>>>>>>>>> WSO2 Inc.; http://wso2.com
>>>>>>>>>>>>>>> lean.enterprise.middleware
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> mobile: +94 772 512 430
>>>>>>>>>>>>>>> skype: jpfonseka
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * <http://lk.linkedin.com/in/rumeshbandara>*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> *Joseph Fonseka*
>>>>>>>>>>>>> WSO2 Inc.; http://wso2.com
>>>>>>>>>>>>> lean.enterprise.middleware
>>>>>>>>>>>>>
>>>>>>>>>>>>> mobile: +94 772 512 430
>>>>>>>>>>>>> skype: jpfonseka
>>>>>>>>>>>>>
>>>>>>>>>>>>> * <http://lk.linkedin.com/in/rumeshbandara>*
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> *Joseph Fonseka*
>>>>>>>>>>> WSO2 Inc.; http://wso2.com
>>>>>>>>>>> lean.enterprise.middleware
>>>>>>>>>>>
>>>>>>>>>>> mobile: +94 772 512 430
>>>>>>>>>>> skype: jpfonseka
>>>>>>>>>>>
>>>>>>>>>>> * <http://lk.linkedin.com/in/rumeshbandara>*
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>> *Sanjeewa Malalgoda*
>>>>>>>>>> WSO2 Inc.
>>>>>>>>>> Mobile : +94713068779
>>>>>>>>>>
>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog
>>>>>>>>>> :http://sanjeewamalalgoda.blogspot.com/
>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> *Sanjeewa Malalgoda*
>>>>>>>>> WSO2 Inc.
>>>>>>>>> Mobile : +94713068779
>>>>>>>>>
>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog
>>>>>>>>> :http://sanjeewamalalgoda.blogspot.com/
>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> --
>>>>>>>> *Joseph Fonseka*
>>>>>>>> WSO2 Inc.; http://wso2.com
>>>>>>>> lean.enterprise.middleware
>>>>>>>>
>>>>>>>> mobile: +94 772 512 430
>>>>>>>> skype: jpfonseka
>>>>>>>>
>>>>>>>> * <http://lk.linkedin.com/in/rumeshbandara>*
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> --
>>>>>>> *Joseph Fonseka*
>>>>>>> WSO2 Inc.; http://wso2.com
>>>>>>> lean.enterprise.middleware
>>>>>>>
>>>>>>> mobile: +94 772 512 430
>>>>>>> skype: jpfonseka
>>>>>>>
>>>>>>> * <http://lk.linkedin.com/in/rumeshbandara>*
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> *Sanjeewa Malalgoda*
>>>>>> WSO2 Inc.
>>>>>> Mobile : +94713068779
>>>>>>
>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog
>>>>>> :http://sanjeewamalalgoda.blogspot.com/
>>>>>> <http://sanjeewamalalgoda.blogspot.com/>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Architecture mailing list
>>>>>> Architecture@wso2.org
>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Nuwan Dias
>>>>>
>>>>> Technical Lead - WSO2, Inc. http://wso2.com
>>>>> email : nuw...@wso2.com
>>>>> Phone : +94 777 775 729
>>>>>
>>>>> _______________________________________________
>>>>> Architecture mailing list
>>>>> Architecture@wso2.org
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> With Regards,
>>>>
>>>> *Rasika Perera*
>>>> Software Engineer
>>>> M: +94 71 680 9060 E: rasi...@wso2.com
>>>> LinkedIn: http://lk.linkedin.com/in/rasika90
>>>>
>>>> WSO2 Inc. www.wso2.com
>>>> lean.enterprise.middleware
>>>>
>>>> _______________________________________________
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> Malintha Amarasinghe
>>> Software Engineer
>>> *WSO2, Inc. - lean | enterprise | middleware*
>>> http://wso2.com/
>>>
>>> Mobile : +94 712383306
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> With Regards,
>>
>> *Rasika Perera*
>> Software Engineer
>> M: +94 71 680 9060 E: rasi...@wso2.com
>> LinkedIn: http://lk.linkedin.com/in/rasika90
>>
>> WSO2 Inc. www.wso2.com
>> lean.enterprise.middleware
>>
>> _______________________________________________
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
> --
> *Joseph Fonseka*
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: +94 772 512 430
> skype: jpfonseka
>
> * <http://lk.linkedin.com/in/rumeshbandara>*
>
>
> _______________________________________________
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
With Regards,
*Rasika Perera*
Software Engineer
M: +94 71 680 9060 E: rasi...@wso2.com
LinkedIn: http://lk.linkedin.com/in/rasika90
WSO2 Inc. www.wso2.com
lean.enterprise.middleware
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
