It would be superb if we are supporting the "expand" parameter without any constraints. But now this becomes a general parameter, we may need to test with other inputs combinations as well. eg: expand with name and pagination limits.
Thanks! On Tue, May 22, 2018 at 1:30 PM Sachini De Silva <[email protected]> wrote: > Hi, > > As per the discussion with team, we are going to send full APIDeatils > whenever get /apis is invoked with expand parameter set as true. In short > expand parameter would not be bound to just api labels feature but will > have the implied meaning in the context. (i.e whatever the resultant API > list will be returned with full details) > > Thanks, > Sachini > > On Tue, May 22, 2018 at 12:09 PM, Malintha Amarasinghe <[email protected] > > wrote: > >> >> >> On Tue, May 22, 2018 at 11:25 AM Sachini De Silva <[email protected]> >> wrote: >> >>> Hi all, >>> >>> This is to clarify a doubt. >>> >>> What should be done when get /apis is invoked with following parameter >>> combination ? >>> >>> expand=true >>> query=name:testAPI (any query that does not contain a label search) >>> >>> Should we return the APIList with full API details or return an error >>> code to indicate this operation is not supported ? >>> >> >> May be responding with *501 Not Implemented?* Shall we also indicate in >> the response error description in the ErrorDTO that, expand attribute is >> only supported when provided label search query? Let's mention the same in >> the "expand" attribute description in the yaml file as well. >> >> Thanks! >> >> >>> >>> Appreciate your suggestions. >>> >>> Thanks, >>> Sachini >>> >>> On Thu, May 17, 2018 at 10:53 PM, Ishara Cooray <[email protected]> >>> wrote: >>> >>>> 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. >>>> +1 >>>> >>>> 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 >>>> >>>> Omitting pagination may lead to out of memory issue if it returns a >>>> large JSON. >>>> What could be the maximum no of APIs that a lable can have? >>>> >>>> Thanks & Regards, >>>> Ishara Cooray >>>> Senior Software Engineer >>>> Mobile : +9477 262 9512 >>>> WSO2, Inc. | http://wso2.com/ >>>> Lean . Enterprise . Middleware >>>> >>>> On Thu, May 17, 2018 at 11:55 AM, Nuwan Dias <[email protected]> wrote: >>>> >>>>> >>>>> >>>>> On Thu, May 17, 2018 at 11:49 AM, Malintha Amarasinghe < >>>>> [email protected]> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Thu, May 17, 2018 at 10:57 AM Nuwan Dias <[email protected]> wrote: >>>>>> >>>>>>> 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 limit is currently defined as a number. How about limit=-1? Or we >>>>>> have to change the limit data type to string. >>>>>> >>>>> >>>>> +1 >>>>> >>>>>> >>>>>> >>>>>>> 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 >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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 >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> 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 >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> -- >> 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 >> >> > > > -- > > *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
