Using /export might confuse with the api export API we have for API Manager 3.0. We should probably use the GET /apis Resource for this as well.
Since we need to search by label, we'll probably need to filter as below GET /apis?query=label:foo Since we need to omit pagination (because in this case we need all results) we may need to do something like this GET /apis?limit=unlimited The GET /apis responds with a partial payload for listing purposes. Since that doesn't work in this case we probably need to support a query param named 'expand'. Ex: GET /apis?expand=true We may need to honor the Accept header to decide on compression. Ex: Accept: application/gzip On Wed, May 16, 2018 at 6:38 PM, Ishara Cooray <[email protected]> wrote: > Hi Sachini, > > Since the response could have more than 1 APIs you will have to consider > about pagination as well. > > For that, you may use existing *APIList *resource in the > publisher-api.yaml > > Thanks & Regards, > Ishara Cooray > Senior Software Engineer > Mobile : +9477 262 9512 > WSO2, Inc. | http://wso2.com/ > Lean . Enterprise . Middleware > > On Tue, May 15, 2018 at 10:08 AM, Sachini De Silva <[email protected]> > wrote: > >> Hi Harsha, >> >> Yes, the response contains the swagger definition of APIs and all fields >> in APIDTO. As for the current implementation labeled apis are returned as a >> json list. (see response.json) To accommodate this I have introduced a new >> DetailedAPIListDTO as below. >> >> DetailedAPIList: >> title: Detailed API List >> properties: >> list: >> type: array >> items: >> $ref: '#/definitions/API' >> >> At the moment I am working on compressing the response. >> >> Thanks, >> Sachini >> >> >> On Mon, May 14, 2018 at 5:39 PM, Harsha Kumara <[email protected]> wrote: >> >>> Hi Sachini, >>> >>> Is swagger definition embed with the response returning from this API? >>> >>> Thanks, >>> Harsha >>> >>> On Wed, May 9, 2018 at 2:49 PM Sachini De Silva <[email protected]> >>> wrote: >>> >>>> 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 >>>> >>> >>> >>> -- >>> 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 >> >> > > _______________________________________________ > 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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
