[Architecture] Creating several versions of same API on APIM REST APIs
Hi, Currently I'm working on a client side tool to perform import and export of APIs in APIM. I encountered conflict issues(error 409) on following instances when using REST APIs to create a new API. 1.when trying to re-import already published API 2.when trying to import a new version of a already published API This is because along API post , initially it check for the context by [1] and throw a conflict exception if context template of the payload and a existing API alike. Several versions of the same API has same *context template* and it should be a exceptional scenario of above mentioned procedure. To handle this hope to do following modifications for apisPost REST API. On API post initially do check [1]. If returns true, get the corresponding API name from the database and check if the API name in the payload and the published API are same. If same, then retrieve all the published versions of that API from the database and check those against version stated in the payload. Method should throws a conflict exception only if the payload holds a already published version of the API or if the API name on the payload and API name in the database corresponds to same context template differs.Else it will allow the normal process of creating a new API.Summary of the proposed changes are shown in Fig.1.0 *Fig.1.0* [1] apiProvider.isDuplicateContextTemplate(body.getContext()) If any feedback please do reply. Regards, Kaveesha -- Kaveesha Perera Intern - Software Engineering mobile: 0716130471 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Creating several versions of same API on APIM REST APIs
Hi, > Shouldn't we use apiProvider.checkIfAPIExists(apiId) as the first check > of POST /apis endpoint? > IMO it is good to start the duplicate check from API Identifier as it is > the unique entry for all the APIs in APIM. > Then we can go for apiProvider.isDuplicateContext > Template(body.getContext()). > +1 , So that we can avoid the creation of APIs with duplicate API name,provider and version, even with different context template. With the above changes, flow will be as follows in Fig 1.1. *Fig. 1.1.* If have any feedback on this approach do reply. Thanks, Kaveesha. On Mon, Sep 12, 2016 at 9:15 AM, Kaveesha Perera wrote: > Hi, > > Currently I'm working on a client side tool to perform import and export > of APIs in APIM. > > I encountered conflict issues(error 409) on following instances when using > REST APIs to create a new API. > 1.when trying to re-import already published API > 2.when trying to import a new version of a already published API > > This is because along API post , initially it check for the context by [1] > and throw a conflict exception if context template of the payload and a > existing API alike. > > Several versions of the same API has same *context template* and it > should be a exceptional scenario of above mentioned procedure. To handle > this hope to do following modifications for apisPost REST API. > > On API post initially do check [1]. If returns true, get the corresponding > API name from the database and check if the API name in the payload and the > published API are same. If same, then retrieve all the published versions > of that API from the database and check those against version stated in the > payload. Method should throws a conflict exception only if the payload > holds a already published version of the API or if the API name on the > payload and API name in the database corresponds to same context template > differs.Else it will allow the normal process of creating a new API.Summary > of the proposed changes are shown in Fig.1.0 > > > *Fig.1.0* > > > > [1] apiProvider.isDuplicateContextTemplate(body.getContext()) > > If any feedback please do reply. > > Regards, > Kaveesha > > -- > Kaveesha Perera > Intern - Software Engineering > > mobile: 0716130471 > -- Kaveesha Perera Intern - Software Engineering mobile: 0716130471 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Exporting a API without Mediation Policies.
Hi all, Currently I'm working on a client side tool to perform import and export of APIs in APIM. On proceeding with importing a exported API, I came across a doubt state, Should we abort the normal process of API import if we failed to upload the corresponding mediation policies of that API, or should we allow the normal API import procedure even without mediation policies? WDYT? Regards, Kaveesha. -- Kaveesha Perera Intern - Software Engineering mobile: 0716130471 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Creating several versions of same API on APIM REST APIs
Hi all, I recently finished above discussed implementation and procedure underwent several modifications to overcome few erroneous situations arose. Current flow with those modifications are summarized in the following Fig 1.2. Please find the corresponding pr in [1]. * Fig 1.2*[1] https://github.com/wso2/carbon-apimgt/pull/3015 If any feedback, please reply. Regards, Kaveesha. On Mon, Sep 12, 2016 at 2:00 PM, Kaveesha Perera wrote: > Hi, > > >> Shouldn't we use apiProvider.checkIfAPIExists(apiId) as the first check >> of POST /apis endpoint? >> IMO it is good to start the duplicate check from API Identifier as it is >> the unique entry for all the APIs in APIM. >> Then we can go for apiProvider.isDuplicateContext >> Template(body.getContext()). >> > +1 , So that we can avoid the creation of APIs with duplicate API > name,provider and version, even with different context template. > > With the above changes, flow will be as follows in Fig 1.1. > > > > > *Fig. 1.1.* > If have any feedback on this approach do reply. > > Thanks, > Kaveesha. > > > On Mon, Sep 12, 2016 at 9:15 AM, Kaveesha Perera > wrote: > >> Hi, >> >> Currently I'm working on a client side tool to perform import and export >> of APIs in APIM. >> >> I encountered conflict issues(error 409) on following instances when >> using REST APIs to create a new API. >> 1.when trying to re-import already published API >> 2.when trying to import a new version of a already published API >> >> This is because along API post , initially it check for the context by >> [1] and throw a conflict exception if context template of the payload and a >> existing API alike. >> >> Several versions of the same API has same *context template* and it >> should be a exceptional scenario of above mentioned procedure. To handle >> this hope to do following modifications for apisPost REST API. >> >> On API post initially do check [1]. If returns true, get the >> corresponding API name from the database and check if the API name in the >> payload and the published API are same. If same, then retrieve all the >> published versions of that API from the database and check those against >> version stated in the payload. Method should throws a conflict exception >> only if the payload holds a already published version of the API or if the >> API name on the payload and API name in the database corresponds to same >> context template differs.Else it will allow the normal process of creating >> a new API.Summary of the proposed changes are shown in Fig.1.0 >> >> >> *Fig.1.0* >> >> >> >> [1] apiProvider.isDuplicateContextTemplate(body.getContext()) >> >> If any feedback please do reply. >> >> Regards, >> Kaveesha >> >> -- >> Kaveesha Perera >> Intern - Software Engineering >> >> mobile: 0716130471 >> > > > > -- > Kaveesha Perera > Intern - Software Engineering > > mobile: 0716130471 > -- Kaveesha Perera Intern - Software Engineering mobile: 0716130471 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] New operation for sequence upload/download in CXF REST API
e":"in",
"config":"http://ws.apache.org/ns/synapse\";
name=\"json_to_xml_in_message\"> "
}
Delete a global mediation policy
This operation can be used to delete an existing Mediation Policy by
proving the uuid of the Mediation Policy
DELETE https://localhost:9443/api/am/admin/v0.10/apis
*/policies/mediation/{uuid}*
*Oauth 2.0 scope *: apim:mediation_policy_create
*Request *:
DELETE https://127.0.0.1:9443/api/am/admin/v0.10/policies/mediation
/6fb74674-4ab8-4b52-9886-f9a376985060
<https://127.0.0.1:9443/api/am/publisher/v0.10/policies/mediation/6fb74674-4ab8-4b52-9886-f9a376985060>
Authorization: Bearer ae4eae22-3f65-387b-a171-d37eaa366fa8
*Response *:
HTTP/1.1 200 OK
Publisher REST APIs on upload/download the* API specific mediation policies*
will accept the same payloads and the returning responses same as above
unless the url of the endpoint directed to,https://127.0.0.1:9443/api/
am/publisher/v0.10/
*apis/{apiId}/policies/mediationAPI Specific Mediation Policies*Retrieve
all API specific mediation policies of a API
GET https://localhost:9443/api/am/publisher/v0.10/apis/
*{apiId}/policies/mediation*
Oauth 2.0 scope : apim:api_view
Request :
GET https://127.0.0.1:9443/api/am/publisher/v0.10/apis/15382857-
dbb2-4749-9c9c-4557c51048e2
<https://127.0.0.1:9443/api/am/publisher/v0.10/policies/mediation>/
policies/mediation
<https://127.0.0.1:9443/api/am/publisher/v0.10/policies/mediation>
Authorization: Bearer ae4eae22-3f65-387b-a171-d37eaa366fa8
Create a new API specific mediation policy
POST https://localhost:9443/api/am/publisher/v0.10/apis/
*{apiId}/policies/mediation*
Oauth 2.0 scope : apim:api_create
Request :
POST https://127.0.0.1:9443/api/am/publisher/v0.10/apis/15382857-
dbb2-4749-9c9c-4557c51048e2
<https://127.0.0.1:9443/api/am/publisher/v0.10/policies/mediation>/po
licies/mediation
<https://127.0.0.1:9443/api/am/publisher/v0.10/policies/mediation>
Authorization: Bearer ae4eae22-3f65-387b-a171-d37eaa366fa8
Get details of a API specific mediation policy
GET https://localhost:9443/api/am/publisher/v0.10/apis/
*{apiId}/policies/mediation/{uuid}*
Oauth 2.0 scope : apim:api_view
Request :
GET https://127.0.0.1:9443/api/am/publisher/v0.10/apis/
<https://127.0.0.1:9443/api/am/publisher/v0.10/policies/mediation/7a2298c4-c905-403f-8fac-38c73301631f>
15382857-dbb2-4749-9c9c-4557c51048e2/
<https://127.0.0.1:9443/api/am/publisher/v0.10/policies/mediation>po
licies/mediation/1813c3e8-d831-4e20-90e3-bbb70d2ca59e
<https://127.0.0.1:9443/api/am/publisher/v0.10/policies/mediation/7a2298c4-c905-403f-8fac-38c73301631f>
Authorization: Bearer ae4eae22-3f65-387b-a171-d37eaa366fa8
Update a existing API specific mediation policy
PUT https://localhost:9443/api/am/publisher/v0.10/apis/
*{apiId}/policies/mediation/{uuid}**Oauth 2.0 scope* : apim:api_create
*Request* :
PUT https://127.0.0.1:9443/api/am/publisher/v0.10/apis/
<https://127.0.0.1:9443/api/am/publisher/v0.10/policies/mediation/7a2298c4-c905-403f-8fac-38c73301631f>
15382857-dbb2-4749-9c9c-4557c51048e2/
<https://127.0.0.1:9443/api/am/publisher/v0.10/policies/mediation>
policies/mediation/1813c3e8-d831-4e20-90e3-bbb70d2ca59e
<https://127.0.0.1:9443/api/am/publisher/v0.10/policies/mediation/7a2298c4-c905-403f-8fac-38c73301631f>
Authorization: Bearer ae4eae22-3f65-387b-a171-d37eaa366fa8
Delete a API specific mediation policy
DELETE https://localhost:9443/api/am/publisher/v0.10/apis/
*{apiId}/policies/mediation/{uuid}**Oauth 2.0 scope *: apim:api_create
*Request *:
DELETE https://127.0.0.1:9443/api/am/publisher/v0.10/apis/
<https://127.0.0.1:9443/api/am/publisher/v0.10/policies/mediation/7a2298c4-c905-403f-8fac-38c73301631f>
15382857-dbb2-4749-9c9c-4557c51048e2/
<https://127.0.0.1:9443/api/am/publisher/v0.10/policies/mediation>po
licies/mediation/1813c3e8-d831-4e20-90e3-bbb70d2ca59e
<https://127.0.0.1:9443/api/am/publisher/v0.10/policies/mediation/7a2298c4-c905-403f-8fac-38c73301631f>
Authorization: Bearer ae4eae22-3f65-387b-a171-d37eaa366fa8
If any modifications should be done on above, please reply.
Regards,
Kaveesha
--
Kaveesha Perera
Intern - Software Engineering
mobile: 0716130471
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Client side tool for API import/ export feature of APIM
Hi all, Recently i finished developing a client side tool to perform import and export of APIS in APIM.This is a brief description about the tool and its basic functionality. Please find the corresponding repository in [1]. Tool is simply a jar file where user can configure using a external configuration file or using command line parameters passing along jar execution. (however tool is per-configured with default configurations) Using this tool, can perform single API export and bulk API export depending on the user's configuration on the tool. User can pass a list of APIs in CSV file and export them all together with their association information as thumbnails, documents, wsdl and mediation policies to be export at once and create a single exportable file. Exportable file structure will be as Fig 1.1 . All the information regarding each APIs are retrieved through available publisher and admin REST APIs available and write in to the folder been exporting. For that user should be log in to the system using valid credentials and obtain access tokens with required scopes. Fig 1.1 Inside each API folder, structure will be as in Fig 1..2 Fig 1.2 Tool also support single and bulk import of APIs depending on the no of APIs inside the imported folder. (As in Fig 1.1, no of APIs to be import will be 3). Process involve in reading each component inside the imported folder and create new APIs together with related associations depending on the compatibilities as authorization etc. This is also achieved by calling available admin and publisher REST APIs. User should login with valid credentials and obtain access tokens with valid scopes to perform the procedure. This is the basic functionality of the tool and more comprehensive documentation will be available in [1] soon . [1] https://github.com/knPerera/importExport If have any feed back please do reply. Regards, Kaveesha. -- Kaveesha Perera Intern - Software Engineering mobile: 0716130471 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Improvements for API import/export base on APIM REST API
Hi All,
Current import/export tool of APIM is based on APIM internal Java API
implementations for its functionality, Which been lead to tight coupling
between the code and the API. This make restrictions on API maintenance
across versions and code changes.
Recently I'm working on modifying import/export tool to use APIM REST API
implementations to perform it's functionalities.This will add more dynamic
nature to APIs irrespective to the changes in code bases.
I'm completed with the first phase of the above by exporting a API using
REST APIs.
Invoking a REST API require access token.Before that need to obtain the
consumer key/secret key pairs. To obtain consumer key/secrete pairs and
access tokens implemented a Java client to call dynamic client registration
endpoint to as in 1)
https://docs.wso2.com/display/AM1100/apidocs/publisher/index.html#guide.
I changed the current implementations of import/export to retrieve the
information related to a particular API using REST API. Following REST APIs
are used over that. These need access token with scope *apim:api_view*.
- Get details of an API-
https://docs.wso2.com/display/AM1100/apidocs/publisher/index.html#!/operations#APICollectionApi#apisApiIdGet
- Get API documentations -
1)https://docs.wso2.com/display/AM1100/apidocs/publisher/index.html#!/operations#APIDocumentApi#apisApiIdDocumentsGet
-2)
https://docs.wso2.com/display/AM1100/apidocs/publisher/index.html#!/operations#APIDocumentApi#apisApiIdDocumentsDocumentIdContentGet
- Get thumbnail image - retrieve by calling endpoint
http://localhost:9763/api/am/publisher/v0.9/apis/{apiId}/thumbnail
- Information on the swagger included withing the retrieved API
definition.
All the information of the existing API, retrieved from above are written
in to a directory which can be export as a .zip archive. This exporting ZIP
file contains the following structure:
If any feedback please reply.
Regards,
--
Kaveesha Perera
Intern - Software Engineering
mobile: 0716130471
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Facilitating Updating API with import/export tool in APIM
Hi All,
Current import/export tool doesn't facilitate updating a imported API. I
modified the implementation of import/export tool in APIM to update a API
once its been try to import a already imported API using APIM REST API.
When a user attempt to import a existing API using *"*create a new API*" *REST
API [ 1.
https://docs.wso2.com/display/AM1100/apidocs/publisher/#!/operations#APICollectionApi#apisPost]
, server gives out a error with code 409 stating a conflict. On it, then
check whether the user has set the value of query parameter
"updateIfExists" to true.(Refer the following example)
eg :-
curl -H "Authorization:Basic AbCdEfG" -F file=@
"/Desktop/MyAPIFolder/myExportedAPI.zip" -k -X POST "
https://10.100.7.40:9443/api-import-export-/import-api?
*updateIfExists=true*"
If then, update the existing API using following REST APIs,
- Update the existing API -
https://docs.wso2.com/display/AM1100/apidocs/publisher/#!/operations#APICollectionApi#apisApiIdPut
- Delete the existing API documents -
https://docs.wso2.com/display/AM1100/apidocs/publisher/#!/operations#APIDocumentApi#apisApiIdDocumentsDocumentIdDelete
- Add exported API documents -
https://docs.wso2.com/display/AM1100/apidocs/publisher/#!/operations#APIDocumentApi#apisApiIdDocumentsPost
- Update document contents -
https://docs.wso2.com/display/AM1100/apidocs/publisher/#!/operations#APIDocumentApi#apisApiIdDocumentsDocumentIdContentPost
- Add API thumbnail by calling to the end point
http://localhost:9763/api/am/publisher/v0.9//apis/{apiId}/thumbnail
<http://www.google.com/url?q=http%3A%2F%2F127.0.0.1%3A9763%2Fapi%2Fam%2Fpublisher%2Fv0.9%2F%2Fapis%2Ff7ac5958-e581-4631-9c39-bb7d0795cf7c%2Fthumbnail&sa=D&sntz=1&usg=AFQjCNEpM0xz1acxH3fPPubOP-RG_WhTsA>
with corresponding image file.
else, If the value of query parameter "updateIfExists" is false, importing
action ends up giving a appropriate error message stating API trying to
create already exists.
If there are any feedback on this procedure please reply.
Regards,
--
Kaveesha Perera
Intern - Software Engineering
mobile: 0716130471
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Improvements for API import/export base on APIM REST API
Hi Rasika, your suggestions on .zip archive were accepted and changed the structure accordingly. Purpose of* FileContents* folder is to hold the corresponding file of a API document with source type "FILE". "FILE" type documents are maintained inside this folder to overcome the conflict that will arise at any case between docs.json and the document file, if a file named "docs.json" uploaded as a *FILE* source typed document. *InlineContents* folder is used to store API document content with source type "In-line". And yes, this structure is valid for both REST and SOAP. Regards, On Tue, Jul 19, 2016 at 2:01 PM, Rasika Perera wrote: > Hi Kaveesha, > > Current import/export tool of APIM is based on APIM internal Java API >> implementations for its functionality, Which been lead to tight coupling >> between the code and the API. This make restrictions on API maintenance >> across versions and code changes. >> Recently I'm working on modifying import/export tool to use APIM REST API >> implementations to perform it's functionalities.This will add more dynamic >> nature to APIs irrespective to the changes in code bases. >> I'm completed with the first phase of the above by exporting a API using >> REST APIs. > > +1 for allowing import/export capabilities through the REST-APIs. > > Few suggestions on the structure of the .zip archive; > > - >|-meta-info <- renamed : all in > simple case would simplify case-sensitive problems >| |---api.json >| `--swagger.json >|-docs<- renamed : all in > simple case would simplify case-sensitive problems >| |FileContents <- what'd be the > purpose of this folder? >| |InlineContents<- what'd be purpose of > this folder? >| `---docs.json >|-thumbnail. <- removed folder : since > there's one image. renamed: thumbnail is more suitable IMO. >|-sequences <- renamed : all in > simple case would simplify case-sensitive problems >| |fault-sequence >| |in-sequence >| `out-sequence >`--.wsdl <- removed folder : since there's > only one wsdl > > Does above structure valid for both REST and SOAP? > > Thanks, > Rasika > > -- > With Regards, > > *Rasika Perera* > Software Engineer > LinkedIn: http://lk.linkedin.com/in/rasika90 > > [image: wso2-signature-general.png] <https://wso2.com/signature> > > WSO2 Inc. www.wso2.com > lean.enterprise.middleware > -- Kaveesha Perera Intern - Software Engineering mobile: 0716130471 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Facilitating Updating API with import/export tool in APIM
Hi All,
Earlier API Manager doesn't included a separate REST API for it's
functionality. Import/export API directly called implementation layer for
its operations.
As API Manager consists of a REST API now, api-import-export tool was
implemented to consume it instead of directly accessing the implementation
layer. Currently clients calls the import/export API then import/export API
calls publisher REST API, which interact with implementations and perform
import and export of APIs. [Refer *Diagram 1.0* ]
*Diagram 1.0*
As Rasika suggested, if we added a new resource to the existing publisher
REST API for api import and export, it will generate a situation where API
calls another API for it's functionality, which is the same scenario
currently prevailing. So we are hoping to move forward with import/export
as follows.
We are hoping integrate the tasks of import/export API into a .jar which
will be deploy and execute as a client app and then client app will
directly consume REST API for import/export operations.[Refer *Diagram 1.1*
]
* Diagram 1.1*
If you have any feedback on this procedure please reply.
Regards,
On Wed, Jul 20, 2016 at 12:33 PM, Rasika Perera wrote:
> Hi Thilini,
>
> Api-import-export tool performs as a separate RESTful API based *tool* which
>> consumes API Manager publisher REST API.
>> Therefore IMO it is not correct to add import-export as a resource to our
>> publisher REST API.
>
> Yes, import-export is not a generic resource. This is kind of a special
> case. My main concern is it should belongs to the *publisher*.
>
> Well, this is how I derived the api;
>
> 1. Import/Export is affected to the resources
> https://apis.wso2.com/api/am/publisher/v0.9/apis/{apiId} and
> https://apis.wso2.com/api/am/publisher/v0.9/apis/{apiId}/documents/{documentId}
> . If we consider following api
> https://10.100.7.40:9443/api-import-export-/import-api.
> It does not convey that import exports are belongs to the resource "apis".
>
> 2. Then it should be; https://10.100.7.40:9443/*apis*/
> import-export-/import-api
>
> 3. Do we need sub-resource import-api? no. We can derive those from PUT,
> POST(import) and GET(export). Hence https://10.100.7.40:9443/*apis*/
> import-export.
>
> 4. Can every user import-export APIs? no. Most of the time, publisher does
> it. Hence final api; https://10.100.7.40:9443/*publisher*/*apis*
> /import-export/.
>
> WDYT?
>
> Thanks,
> Rasika
>
> On Wed, Jul 20, 2016 at 10:06 AM, Thilini Cooray
> wrote:
>
>> Hi Rasika,
>>
>> Api-import-export tool performs as a separate RESTful API based *tool*
>> which consumes API Manager publisher REST API.
>> Therefore IMO it is not correct to add import-export as a resource to our
>> publisher REST API.
>>
>> WDYT?
>>
>> Thanks.
>>
>>
>> On Tue, Jul 19, 2016 at 2:39 PM, Rasika Perera wrote:
>>
>>> Hi Kaveesha,
>>>
>>> Few suggestions on the REST API for import-export.
>>>
>>> eg :-
>>>> curl -H "Authorization:Basic AbCdEfG" -F file=@
>>>> "/Desktop/MyAPIFolder/myExportedAPI.zip" -k -X POST "
>>>> https://10.100.7.40:9443/api-import-export-/import-api?
>>>> *updateIfExists=true*"
>>>
>>> Isn't API import/export apis belongs to publisher? Or is
>>> api-"import-export-" is an api on a jaggery app?
>>>
>>> How about following APIs on publisher?
>>>
>>> https://apis.wso2.com/api/am/publisher/v0.9/apis/{apiId} - [already
>>> exists][1]
>>>
>>> https://apis.wso2.com/api/am/publisher/v0.9/apis/{apiId}/documents/{documentId}
>>> [already exists][2]
>>> https://apis.wso2.com/api/am/publisher/v0.9/apis/{apiId}/import-export
>>> [new]
>>>
>>> *Importing API*
>>> PUT https://apis.wso2.com/api/am/publisher/v0.9/apis/
>>> <https://apis.wso2.com/api/am/publisher/v0.9/apis/%7BapiId%7D/import-export>
>>> {apiId}/
>>> <https://apis.wso2.com/api/am/publisher/v0.9/apis/%7BapiId%7D/import-export>
>>> import-export
>>> <https://apis.wso2.com/api/am/publisher/v0.9/apis/%7BapiId%7D/import-export>
>>>-> Update if exists API+Docs
>>> POST
>>> https://apis.wso2.com/api/am/publisher/v0.9/apis/{apiId}/import-export
>>> -> Create a new API + Docs (Gives 409 if exists)
>>>
>>> *Export API*
>>> GET https://apis.wso2.com/api/am/publisher/v0.9/apis/{apiId}/import-export
>>>-> Export API
>>>
>>> Regards,
&
[Architecture] Bulk export of APIs via APIM
Hi All, I'm planing to improve APIM import/export tool to support bulk import and bulk export of APIs. When considering the bulk export, there it came up to a discussion point on how to get the API list to be export. Considering several facts, came up with two suggestions as follows. [1]. Asking user to submit a file with explicitly written list of APIs. (API detail may include name, version and provider) [2]. Getting the prevailing list of APIs using getAllAPIs REST API, save the usable content of resulting string in a separate file, then allow user to edit it such that he can remove the unwanted APIs from the list, use it as a input for the bulk export. Currently we prefer procedure [1], since the process [2] creates additional overhead due to the REST API call. Still there can be are pros and cons in both the processors. If any opinions on above and any options please do reply. Regards. -- Kaveesha Perera Intern - Software Engineering mobile: 0716130471 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] OAuth Life cycle in client side tool of APIM import/export
Hi all, Currently I'm working on a client side tool that consumes REST APIs for API import/export feature of APIM (Refer to my previous email labeled [1]). There OAuth life cycle goes as follows. User asked to give a application name on the configuration file.Using that, tool create a client application calling DCR endpoint to obtain consumer keys and consumer secretes required to generate tokens that are needed for import and export of APIs. In the case where user didn't provide any application name, tool's default name will be used for the above. If the application already exists and only if the user is the owner of that particular application, consumer key and the consumer secret of the existing application will be returned by the DCR endpoint. If any feedback on this process please do reply. *[1] Facilitating Updating API with import/export tool in APIM * Regards, -- Kaveesha Perera Intern - Software Engineering mobile: 0716130471 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
