Adding the metadata inline ( see below). Looks ok from what I can
understand. Please review with the team and get this right. It will be hard
to change once it is released.
Where would be the Swagger for the API? do we point to that?
Can backend service can also be Swagger of WADL?
--Srinath
{
"id": {
"providerName": "admin",
"apiName": "Test2",
"version": "1.0.0"
},
"wadlUrl": "
http://10.100.7.39:9765/jaxrs_starbucks_service/services/Starbucks_Outlet_Service?_wadl
",
"context": "/test2/1.0.0",
"contextTemplate": "/test2/{version}",
"tags": [],
"documents": [],
"lastUpdated": "Apr 28, 2015 1:51:52 PM",
"availableTiers": [
{
"name": "Bronze",
"displayName": "Bronze",
"description": "Allows 1 request(s) per minute.",
"policyContent": ...
}
],
"uriTemplates": [
{
"uriTemplate": "/*",
"httpVerb": "GET",
"authType": "Any",
"httpVerbs": [
"GET",
"POST",
"PUT",
"DELETE",
"OPTIONS"
],
"authTypes": [
"Any",
"Any",
"Any",
"Any",
"None"
],
"throttlingTier": "Unlimited",
"throttlingTiers": [
"Unlimited",
"Unlimited",
"Unlimited",
"Unlimited",
"Unlimited"
],
"mediationScript": "null",
"scopes": [
null,
null,
null,
null,
null
],
"mediationScripts": {}
}
],
"apiHeaderChanged": false,
"apiResourcePatternsChanged": false,
"status": "CREATED",
"visibility": "public",
"endpointSecured": false,
"transports": "http,https",
"inSequence": "log_in_message",
"outSequence": "log_out_message",
"faultSequence": "json_fault",
"advertiseOnly": false,
"endpointConfig": "{\"production_endpoints\":{\"url\":\"
http://10.100.7.39:9765/jaxrs_starbucks_service/services/Starbucks_Outlet_Service\
",\"config\":null},\"endpoint_type\":\"http\"}",
"responseCache": "Disabled",
"cacheTimeout": 300,
"destinationStatsEnabled": "Disabled",
"implementation": "endpoint",
"scopes": [],
"isDefaultVersion": false,
"isPublishedDefaultVersion": false,
"environments": [
"Production and Sandbox"
],
"rating": 0.0,
"isLatest": true
}
On Wed, May 6, 2015 at 10:59 AM, Thilini Cooray <[email protected]> wrote:
> Hi,
>
> Herewith I have attached meta info .json file for API name Test2.
> Schema for this json is the API model that we are manipulating in the
> source.
>
> Regarding WADL, we mean the WADL of the backend service not a WADL of our
> API.
>
> API Manager allows users to provide WSDL and WADL URLs of the backend
> services when creating APIs.
> At the moment we only store a copy of the WSDL as a registry resource.
> The project structure is designed to keep those resources.
>
> Please give me your feedback on the meta info representation.
>
> Thanks.
> Thilini.
>
>
>
> On Wed, May 6, 2015 at 9:50 AM, Srinath Perera <[email protected]> wrote:
>
>> Thilini, can you send a sample JSON for meta info. We need to discuss and
>> finalize it in this thread.
>>
>> If we only support Swagger, you listed WADL in your project structure you
>> export. Why?
>>
>> On Tue, May 5, 2015 at 9:43 PM, Thilini Cooray <[email protected]> wrote:
>>
>>> Hi,
>>>
>>> *Regarding Isabelle's concerns,*
>>>
>>> a) This feature will be available as a custom application. Therefore we
>>> decided to package this as a WAR.
>>> b) The QoS details will also be stored in the API
>>> c) Swagger file is also inside the meta information.
>>>
>>> *Regarding Srinath's concerns,*
>>>
>>> We are storing meta-information in JSON format.
>>>
>>> We only support Swagger and it will be stored under meta information.
>>>
>>> Regarding sequences and environment specific setup, shall we allow
>>> importing users to add them according to their preference?
>>>
>>> Appreciate your feedback on this.
>>>
>>> Thank you.
>>> Thilini.
>>>
>>>
>>>
>>>
>>>
>>> On Tue, May 5, 2015 at 8:36 AM, Srinath Perera <[email protected]> wrote:
>>>
>>>> Hi Thilini,
>>>>
>>>> What is the format of meta information? we need to discuss that also in
>>>> this thread.
>>>>
>>>> Do we support both Swagger and WADL? if yes Swagger should go in the
>>>> archive and we have to decide where.
>>>>
>>>> Regarding ESB sequences, one option is to export the API without
>>>> sequences and let users add sequences via UI or configurations. ( Same
>>>> approach we took with Services and Axis2 modules years ago.)
>>>>
>>>> --Srinath
>>>>
>>>> On Mon, May 4, 2015 at 3:36 PM, Isabelle Mauny <[email protected]>
>>>> wrote:
>>>>
>>>>> All,
>>>>>
>>>>> Can you please confirm:
>>>>> a) That the packaging is a CApp (i.e. talks to API Manager deployer).
>>>>> b) Where is the QOS setup stored ( the managed part ) - For backup
>>>>> purposes, it would be great to attach QoS to the API. or do we assume that
>>>>> users will have to attach the QoS part manually (i.e.. after deployment we
>>>>> get an API in CREATE mode).
>>>>> c) Where is the Swagger file describing the API stored ? As part of
>>>>> meta-data ?
>>>>>
>>>>> I don't think sequences themselves should be there, just the link.
>>>>> Sequences are reusable across APIs and must not be deployed as part of the
>>>>> API itself. However, I should be able to package a set of sequences and
>>>>> deploy them to an API Manager (again, as CApp, as we do for the ESB). The
>>>>> sequences themselves can be managed/versioned/ separately.
>>>>>
>>>>> As for the tiers etc, those are dependent setup that must be in place
>>>>> before you import in the target environment - Part of the env preparation.
>>>>> We could create an import/export for that too (it's a simple check.out/
>>>>> check.in from registry). Same applies to workflows, store
>>>>> definitions, etc.
>>>>>
>>>>> Isabelle.
>>>>> __________________________________________________
>>>>>
>>>>>
>>>>> *Isabelle Mauny*VP, Product Management; WSO2, Inc.; http://wso2.com/
>>>>> On Apr 22, 2015, at 4:38 PM, Colin Roy-Ehri <[email protected]> wrote:
>>>>>
>>>>> Hi!
>>>>>
>>>>> I'm really excited about this feature - it will be of great benefit to
>>>>> our customers.
>>>>>
>>>>> I have no improvements to suggest on your implementation plan.
>>>>>
>>>>> One point you might want to work into your tests is to ensure the
>>>>> swagger definitions remain consistent after an import/export. Of
>>>>> particular concern is the swagger YAML definitions available through the
>>>>> publisher. It shouldn't be too hard to code into a test. :)
>>>>>
>>>>> Thanks,
>>>>> Colin
>>>>>
>>>>> Thanks,
>>>>> Colin Roy-Ehri
>>>>> Software Engineer
>>>>> *WSO2, Inc. : wso2.com <http://wso2.com/>*
>>>>> *Mobile* : 812-219-6517
>>>>>
>>>>> On Wed, Apr 22, 2015 at 7:15 AM, Thilini Cooray <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> We are in the process of introducing API Export and Import feature
>>>>>> for WSO2 API Manager.
>>>>>>
>>>>>> This feature can be used in scenarios such as moving APIs from
>>>>>> staging to production environment.
>>>>>>
>>>>>> *API Export*
>>>>>>
>>>>>> - This operation mainly sends an archive which consists of all
>>>>>> the required resources for a API to be recreated in another API
>>>>>> Manager
>>>>>> instance.
>>>>>> - We have identified following folder structure to be included in
>>>>>> the archive
>>>>>>
>>>>>> <Screen Shot 2015-04-22 at 3.20.47 PM.png>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *API Import*
>>>>>>
>>>>>> - Import feature accepts an API archive with the above mentioned
>>>>>> structure and create a new API under current provider.
>>>>>>
>>>>>> *Feature Implementation*
>>>>>>
>>>>>> - Generating archive (in API export) and extracting archive (in
>>>>>> API import) can either be done in server or client side
>>>>>> - Currently we are planning to develop a RESTful API for export
>>>>>> and import functionality where archive generation for requested APIs
>>>>>> and
>>>>>> all the related functionality are taken place in the server side.
>>>>>> - Decision for server side implementation was mainly made due to
>>>>>> high number of network calls and high possibility of network failures
>>>>>> that
>>>>>> can happen in client side.
>>>>>> - The RESTful service is halfway done. currently it can export
>>>>>> and import meta information only.
>>>>>> - *Export API* method calls
>>>>>> org.wso2.carbon.apimgt.api.APIProvider.getAPI(APIIdentifier)
>>>>>> and transforms received API object to a json file.
>>>>>> - *Import API* method receives json file via RESTful call and
>>>>>> converts the json to an API object. This object is then sent to
>>>>>> org.wso2.carbon.apimgt.api.APIProvider.addAPI(api) method and
>>>>>> a new API will get created.
>>>>>> - Several concerns can arise with this implementation approach
>>>>>> 1. API object can have environment specific details which are
>>>>>> not compatible with the importing environment
>>>>>> 2. There are some customisable attributes such as tiers (Ex :
>>>>>> tiers in exporting environment may not be available in importing
>>>>>> side)
>>>>>> which may not be available on the importing environment
>>>>>> - Therefore we would like to know whether there is a better
>>>>>> approach for implementing this.
>>>>>>
>>>>>> Suggestions and ideas for implementing this export import API feature
>>>>>> is highly welcome.
>>>>>>
>>>>>> Thank you.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best Regards,
>>>>>>
>>>>>> *Thilini Cooray*
>>>>>> Software Engineer
>>>>>> Mobile : +94 (0) 774 570 112 <%2B94%20%280%29%20773%20451194>
>>>>>> E-mail : [email protected]
>>>>>>
>>>>>> WSO2 Inc. www.wso2.com
>>>>>> lean.enterprise.middleware
>>>>>>
>>>>>> _______________________________________________
>>>>>> Architecture mailing list
>>>>>> [email protected]
>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Architecture mailing list
>>>>> [email protected]
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Architecture mailing list
>>>>> [email protected]
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> ============================
>>>> Srinath Perera, Ph.D.
>>>> http://people.apache.org/~hemapani/
>>>> http://srinathsview.blogspot.com/
>>>>
>>>> _______________________________________________
>>>> Architecture mailing list
>>>> [email protected]
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> Best Regards,
>>>
>>> *Thilini Cooray*
>>> Software Engineer
>>> Mobile : +94 (0) 774 570 112 <%2B94%20%280%29%20773%20451194>
>>> E-mail : [email protected]
>>>
>>> WSO2 Inc. www.wso2.com
>>> lean.enterprise.middleware
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> [email protected]
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> ============================
>> Srinath Perera, Ph.D.
>> http://people.apache.org/~hemapani/
>> http://srinathsview.blogspot.com/
>>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Best Regards,
>
> *Thilini Cooray*
> Software Engineer
> Mobile : +94 (0) 774 570 112 <%2B94%20%280%29%20773%20451194>
> E-mail : [email protected]
>
> WSO2 Inc. www.wso2.com
> lean.enterprise.middleware
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
============================
Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
Site: http://people.apache.org/~hemapani/
Photos: http://www.flickr.com/photos/hemapani/
Phone: 0772360902
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
