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
