Hi, @Harsha Decided to return all information in APIDTO for each API as the response. (not only swagger definition, name, version, context and provider)
Thanks, Sachini On Wed, May 9, 2018 at 1:59 PM, Harsha Kumara <[email protected]> wrote: > @Sachini Can you also add a sample response as well? > > On Wed, May 9, 2018 at 8:02 AM, Malintha Amarasinghe <[email protected]> > wrote: > >> Hi, >> >> >> On Tue, May 8, 2018 at 6:10 PM, Sachini De Silva <[email protected]> >> wrote: >> >>> Hi all, >>> >>> Proposed resource structure is as below. >>> >>> >>> /exports/apis: >>> >> >> +1. I think this looks more like generic export resource which is not >> really specific for the ballerina gw feature. I think it is okay as we can >> use this for any other future requirements which needs API export >> facilities. >> >> >> >>> get: >>> x-scope: apim:api_export >>> >> +1 >> >>> >>> produces: >>> - application/x-gzip >>> >> Not sure this is the most suitable content type we need >> among application/zip, application/gzip and application/x-gzip? >> >> To choose a better one, I think we need to think about what structure we >> are going to give a response with API information. >> >> Will it be a compressed file with a set of folders that containing each >> API's information? >> >> >>> summary: Return apis categorized into a label. >>> description: | >>> This operation can be used to fetch APIs categorized into a >>> certain label. >>> parameters: >>> - name: labelId >>> in: query >>> required: true >>> type: string >>> >> >> Since this is a "required" query parameter, we can think of *GET >> /exports/apis/{labelId} *as well. But if we use this, we will loose the >> opportunity to define *GET /exports/apis/{apiId} *in future to export a >> single API. So +1 for the query parameter. >> >> Thanks! >> >>> >>> responses: >>> 200: >>> description: | >>> OK. >>> schema: >>> type: file >>> headers: >>> Content-Type: >>> description: | >>> The content type of the body. >>> type: string >>> >> >>> 404: >>> description: | >>> Not Found >>> Resource to be fetched does not exist. >>> schema: >>> $ref: '#/definitions/Error' >>> >>> >>> A new scope apim:export_apis will be added and the new resource will be >>> protected by that. >>> The returned file will contain necessary details to create ballerina >>> files for the APIs. This includes,API name, version, provider, context, API >>> swagger definition of each API that satisfies the label query. >>> >>> >>> Thanks, >>> >>> Sachini >>> >>> >>> On Fri, May 4, 2018 at 10:42 AM, Krishan Wijesena <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Fri, May 4, 2018 at 9:57 AM, Sachini De Silva <[email protected]> >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> >>>>> *Design Overview* >>>>> I am working on developing a REST API to fetch API details to APIM >>>>> gateway from the publisher. Fetching of APIs is based on labels, i.e as >>>>> mentioned in [1] a certain set of APIs can be grouped into a certain >>>>> gateway instance by a label. When setting up the gateway the user executes >>>>> following command followed by user credentials. >>>>> >>>>> setup <label> >>>>> >>>>> Then a request for APIs labeled with <label> is sent to API publisher. >>>>> The response to this is, API details as a compressed JSON. Then based on >>>>> the retrieved details b7a project structure for the gateway instance will >>>>> be created and deployed. >>>>> >>>> >>>> How we handle the permission restrictions here? for example if label >>>> X attached to API1, UserA do not have permission to view API1(restricted by >>>> roles) called setup<labelX> and he should not get that API1 with compressed >>>> JSON? or do we provide all the API with label X to that perticulr userA? >>>> >>>>> >>>>> So ideally I should be able to do this by adding a new resource to >>>>> publisher-api.yaml to fetch APIs by label. Then this resource call has to >>>>> be mapped to where the setup command is executed. >>>>> >>>>> Suggestions are highly appreciated. >>>>> >>>>> Related mail threads : >>>>> [1] [Architecture][APIM] Label feature for API-Manager gateway >>>>> [2] [Architecture][APIM][API-Manager gateway] Attaching Labels for >>>>> APIs >>>>> >>>>> Thanks, >>>>> Sachini >>>>> >>>>> -- >>>>> >>>>> *Sachini De Silva* >>>>> Software Engineer - WSO2 >>>>> >>>>> Email : [email protected] >>>>> Mobile : +94714765495 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> *Krishan Wijesena* >>>> Software Engineer | WSO2 >>>> >>>> Email : [email protected] >>>> Mobile : +94776219923 >>>> WSO2 Inc : http://wso2.com >>>> [image: http://wso2.com/signature] <http://wso2.com/signature> >>>> >>> >>> >>> >>> -- >>> >>> *Sachini De Silva* >>> Software Engineer - WSO2 >>> >>> Email : [email protected] >>> Mobile : +94714765495 >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Malintha Amarasinghe >> *WSO2, Inc. - lean | enterprise | middleware* >> http://wso2.com/ >> >> Mobile : +94 712383306 >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Harsha Kumara > Software Engineer, WSO2 Inc. > Mobile: +94775505618 > Blog:harshcreationz.blogspot.com > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Sachini De Silva* Software Engineer - WSO2 Email : [email protected] Mobile : +94714765495
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
