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 ?
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
