Hi Jochen, Sorry I missed your reply.
On Wed, Jan 11, 2017 at 4:40 PM, Jochen Traunecker < [email protected]> wrote: > HI Isuru, > > please consider these requirements, too: > > - It should be possible to introduce a dedicated EXPORTER and IMPORTER > role (scope) with less privileges than ADMIN. Just be to able to EXPORT > (IMPORT). > Assume you are suggesting to allow exporting/importing all APIs for a non-admin user with these roles, IMHO that might mean one user can actually change another user's APIs, etc. Wouldn't it be better to allow this only for a user with admin privileges? > - It should be possible to IMPORT APIs on behalf of a user. This would be > very helpful when staging APIs, by that not the mostly technical "IMPORT" > user will be the "creator" of an API (same applies to other API-calls like > publishing an API). > This is possible if we go with the approach where users with admin privileges can import all APIs. > - It should be possible to EXPORT a subset of APIs based on TAG(s) and > maybe other attributes > +1 for supporting a search mechanism. > > Thanks, > Jochen > > Akalanka Pagoda Arachchi <[email protected]> schrieb am Mi., 11. Jan. > 2017 um 11:02 Uhr: > >> Hi Isuru, >> >> Will importing an already available API updated the existing API? This >> would be useful for someone when following agile development to create APIs. >> >> What are the options provided to update the endpoint URIs? For an example >> if an API is created in a UAT environment and need to move that to PROD, >> how can someone update the endpoints URIs to match the PROD environment. >> >> Thanks, >> Akalanka. >> >> On Wed, Jan 11, 2017 at 3:15 PM, Isuru Haththotuwa <[email protected]> >> wrote: >> >> >> >> On Wed, Jan 11, 2017 at 11:01 AM, Nuwan Dias <[email protected]> wrote: >> >> >> >> On Tue, Jan 10, 2017 at 11:22 AM, Isuru Haththotuwa <[email protected]> >> wrote: >> >> Hi Devs, >> >> This is to discuss subject. >> >> *Requirement:* >> >> Once an API is exported, its possible to be directly imported in to >> another APIM deployment in a separate environment. For an admin user, it >> should be possible to export all APIs in one deployment to another one. >> >> The following information will be available in exported data, related to >> a single API: >> >> - Docs >> - API definition (JSON formatted) >> - Swagger file (JSON formatted) >> - Gateway configuration >> - API thumbnails (image) >> >> Several new resources will be added to the publisher rest API to cater >> this, as follows: >> >> *GET **/apis/{apiId}**/export-config* >> >> >> I don't think this URI is correct. A user of this API won't know the API >> ID. Hence I think the correct URI should be as *GET >> /export/api?name=Foo&version=v1* >> >> Agreed. Api Id is an internal detail. Hence the correct way should be to >> use api name and version to uniquely identify an API. >> >> >> - Produces a form/multipart output as a zip archive, which will have >> the following structure and which will comprise of the above mentioned >> items: >> >> * <provider-name>-<api-name>-<* >> >> *api-version>.zip |* >> >> >> * | --- Docs | |* >> * | | --- *<documentation_id> >> * | * >> * |* >> * | | ---* documentation >> metadata (json) >> * | | ---* documentation >> content (optional) >> >> * |* >> >> >> * | --- Gateway-Config | >> |* >> * | | --- *gateway config file >> >> * |* >> * | --- *thumbnail file >> >> * |* >> * | --- *api definition (json) >> >> * |* >> * | --- *swagger definition (json) >> >> >> Note that there can be multiple docs for a single API. >> >> *GET **/apis/export-config* >> >> - Produces a zip archive comprising of the above structure for each >> API in the system. This operation will be permitted for admin users only. >> >> >> *POST **/apis**/{apiId}**/import-config* >> >> - Consumes the same zip archive produced by the >> /{apiId/}export-config resource as a form/multipart input, extracts and >> inserts the relevant data. >> >> >> *POST * >> */apis/import-config* >> >> - Consumes the same zip archive produced by the /export-config >> resource as a form/multipart input, extracts and inserts the relevant data >> for all APIs. Should be permitted only for admin users. >> >> >> This does not consider the endpoint information [1] yet. Would need to >> incorporate that here in a suitable way. >> >> Please share your feedback. >> >> [1]. [Architecture] [APIM][C5] - Definining Endpoint for Resource from >> Rest API >> >> -- >> Thanks and Regards, >> >> Isuru H. >> +94 716 358 048 <071%20635%208048>* <http://wso2.com/>* >> >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> >> >> >> -- >> Nuwan Dias >> >> Software Architect - WSO2, Inc. http://wso2.com >> email : [email protected] >> Phone : +94 777 775 729 <077%20777%205729> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> >> >> >> -- >> Thanks and Regards, >> >> Isuru H. >> +94 716 358 048 <+94%2071%20635%208048>* <http://wso2.com/>* >> >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> >> >> >> -- >> *Darshana Akalanka Pagoda Arachchi,* >> *Senior Software Engineer, WSO2* >> *+94777118016 <+94%2077%20711%208016>* >> _______________________________________________ >> 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 > > -- Thanks and Regards, Isuru H. +94 716 358 048* <http://wso2.com/>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
