@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

Reply via email to