Hi,
API Manager Publisher and Store apps will work based on the REST API and
those two apps need the following REST API resources to get the label
information.
*1. Publisher API*
- When creating an API, API creator should select one or more labels. In
order to get the labels, following API will be added.
*GET /labels*
*Response* -
{
"count":2,
"list":[
{
"name":"public",
"access_url":"https://test.cloud.public";
},
{
"name":"private",
"access_url":"https://test.cloud.private";
}
]
}
*2. Store API*
- An API will have one or more label values. This API will be used to get
the label information by giving the list of label names.
*GET /label-info*
*Request* -
{
"labels":[
"public",
"private"
]
}
*Response* -
{
"count":2,
"list":[
{
"name":"public",
"access_url":"https://test.cloud.public";
},
{
"name":"private",
"access_url":"https://test.cloud.private";
}
]
}
Thank you!
On Tue, Feb 14, 2017 at 5:31 PM, Pubudu Gunatilaka <[email protected]> wrote:
> Hi Jochen,
>
> Please find the answers inline.
>
> On Tue, Feb 14, 2017 at 1:52 PM, Jochen Traunecker <
> [email protected]> wrote:
>
>> Hi all,
>>
>> I’m wondering about a few fundamental concepts of C5 based API-Manager
>> and the planned pull approach of deployment of APIs.
>>
>> Topic 1 Will upcoming API-Manager based on C5 support both concepts:
>>
>> Concept A Publisher is aware of Gateway(s) / Clusters of Gateways /
>> Gateway Environments. Gateways still will pull APIs, getting triggered by
>> Publisher (JMS Backchannel) but this is hidden from the users of Publisher.
>> Users still “push” APIs to the Gateway(s), although technically it is the
>> other way around. Users of APIs will get all information about endpoints of
>> APIs in each environment from API-Publisher and they will get informed
>> about API-Publisher about the publishing state (maybe a intermediate state
>> is necessary ‘marked to get published” and ‘successfully published to
>> gateways’).
>>
>> Concept B Publisher is not aware of Gateway(s) at all and just serves
>> API-Definitions, API-Policies and so on. Gateways will pull APIs, maybe
>> still subscribe to a topic of Publisher to get triggered, but it will be
>> totally up to the API-Runtime to manage endpoints and share endpoint
>> information with clients.
>>
>> All concepts are valid use cases and there are environments where all
>> concepts will be in place in parallel.
>>
>
> C5 based API Manager will support only the pull based approach due to the
> drawbacks and feedbacks we received. Some of the drawbacks are mentioned
> above in the mailing thread.
>
>
>>
>> TOPIC 2 Cluster of Gateways: is it planned that each individual member of
>> cluster of Gateways will pull the APIs from Publisher or will there be
>> some manager - worker concept in place where just the manager pulls and
>> triggers the deployment within the cluster? As far as I followed this
>> discussion, there will be no manager - worker concept anymore.
>>
>
> Yes, there will be no manager - worker concept in C5 for gateways. Every
> gateway node needs to pull the relevant API artifact from the publisher
> node.
>
>
>>
>> TOPIC 3 Pulling APIs and JMS : Will it be mandatory to establish a JMS
>> connection between Gateway(s) and Publisher? Or is this an optional
>> feature? Do you have plans to use some messaging protocol that can be used
>> over Websockets ? There are setups, where native JMS connections are not
>> possible at all due to networking policies. Will it be possible to define
>> some periodic timer (or whatever trigger) in Gateway to pull APIs without
>> establishing a JMS / Messaging relationship to Publisher?
>>
>
> As we are going with the pull based approach, we need to have a
> notification mechanism for the gateway node to get the updates of APIs.
> Initial release will have the JMS based notification mechanism. Later
> releases will focus on plugging any other notification mechanisms.
>
>
>> TOPIC 4 Labels and Selectors: Can an API have more than one Label
>> assigned? Can a Gateway ask for APIs using more than one Label? This would
>> end in a n x m relationship which some setups might ask for.
>>
>
> Yes, API can have multiple labels. Also a gateway can have multiple
> labels. When requesting the APIs, gateway node will provide multiple labels
> and if the API is matched with the given labels, API can be retrieved.
>
>
>> TOPIC 5 Abstract APIs / Templates: There are use cases where one API can
>> get deployed into several API-Runtimes (not related to stages). Endpoints
>> of an API are runtime specific (both of them: how to invoke the API as a
>> client and endpoint of to be invoked service). There are planned setups in
>> complex organisations where a centralised API-Management (Store, Publisher
>> and Repository) will manage potentially a lot of API-Runtimes. In each
>> API-Runtime there will be a common set of APIs like services for master
>> data lookup and so on. Each of these common APIs will have its very own
>> endpoint in each API-Runtime (both endpoints, endpoint of the API and the
>> backend service endpoint), but the API by itself is considered to be the
>> “same” across all Runtimes. Will this use case be covered at all as it has
>> some impact on deployment of APIs?
>>
>
> If I rephrase the requirement, an API can have multiple backend enpoints
> for different runtimes. There is a plan to cover this aspect as well.
>
>
>>
>> Looking forward for your feedback.
>>
>> Thanks,
>> Jochen
>>
>> Thank you!
> --
> *Pubudu Gunatilaka*
> Committer and PMC Member - Apache Stratos
> Software Engineer
> WSO2, Inc.: http://wso2.com
> mobile : +94774078049 <%2B94772207163>
>
>
--
*Pubudu Gunatilaka*
Committer and PMC Member - Apache Stratos
Software Engineer
WSO2, Inc.: http://wso2.com
mobile : +94774078049 <%2B94772207163>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
