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

Reply via email to