Hi Sanjeewa,
On Tue, Oct 13, 2015 at 10:46 PM, Sanjeewa Malalgoda <[email protected]>
wrote:
> Hi All,
> API Manager team planned to add complete REST API support for API
> Management operations available in product.
> Since initial implementation is done we are thinking about next steps of
> REST service.
> In this mail we need to discuss about separating API Manager store and
> publisher operations.
>
> *Improvement*
> In current REST API is developed as single web application.
> It will be deployed in API Management server and it can perform both
> store/ publisher operations.
> But so far we had clear separation between API store and
> publisher(Publisher to create/manage APIs and store to manage subscriptions
> etc).
> With new REST API we need to do something similar to manage same behavior.
> This will be important if we deploy API Manager in fully distributed
> deployment. In that case API store will be deployed in DMZ and we shouldn't
> allow publisher operations from that(API create publish should not possible
> from outside).
> To have this kind of separation we may need 2 web applications or single
> web application with 2 contexts.
>
> *Suggested solutions*
> 01. Deploy API Manager store and publisher as 2 separate applications.
> Then we will have 2 applications named api#am#store#v1.war and
> api#am#publisher#v1.war.
> These 2 applications will be deployed in contexts api/am/store/v1
> and api/am/publisher/v1.
> If we deploy store profile we can remove publisher web service and
> if its publisher we can remove store web service.
>
> 02. Have single Applications(web service) which register 2 sub contexts.
> We can define mapped classes according to each context(here contexts
> are api/am/store/v1 and api/am/publisher/v1 ).
> We can add service beans(service beans like apis, applications, tags
> etc) on top of these two base contexts.
> If we deploy store profile we need to disable service bean group for
> publisher. To do this we need to edit beans.xml and redeploy .war file.
>
> If we go for first approach we will have 2 applications and it do not
> require web application modifications.
>
> *Challenges*
> When we implement 2 different services for API store and publisher there
> will be some duplicates.
> As example we can consider following
> /apis GET in publisher will return complete API details with back end urls
> etc.
> But /apis GET in store will return us only detail required for store
> functionality(in this case back end user will not present in response
> instead it will have gateway API URL).
> Same applies for tiers as well(we can edit tiers in publisher but in store
> we can see available tier name list when we subscribe to API).
> So we need to carefully separate these functionalities.
>
If I understood correctly, difference in object models will only come into
effect when creating the output/accepting inputs at the REST API layer. But
when performing a core operation (persisting an API or retrieving it,
publishing an API etc...), the App specific model will be converted to a
single format (a domain specific model).
For example, the API model used in Publisher REST API, will have more
fields than the one used in Store REST API. So outputs when called a GET on
/publisher/apis/{apiId} and a GET on /store/apis/{apiId} will be
different. But from the point where the API is retrieved from the
database/registry, to the point where it's handed over to REST API, the API
will be represented using one model.
So AFAIU even there are duplicates, those duplicates will only exist at the
REST API layer. Core operations won't get duplicated.
Even from a security point of view, it's good to have two different models
(since it minimises the risk of exposing unwanted information Publicly, for
example revealing backend endpoints at Store App) +1 for the keeping two
Apps, which uses two different models.
>
> If we go for 2 different applications sometimes we may need 2 different
> api.yaml files to maintain operation isolation.
> Main reason for that is API object return from publisher API may different
> from API object return from store API.
> So there will be 2 models for API object based on service
> type(store/publisher).
> Or other option is maintain single data model and fill required data based
> on used service(if its publisher back end URL parameter will present with
> value but if its store then back end URLs will not be there).
> We need to discuss this and come to conclusion.
>
> I'm sure we need to focus on this when we implement ES REST API.
> Appreciate your suggestions and comments on this.
>
> Thanks,
> sanjeewa.
>
> --
>
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94713068779
>
> <http://sanjeewamalalgoda.blogspot.com/>blog
> :http://sanjeewamalalgoda.blogspot.com/
> <http://sanjeewamalalgoda.blogspot.com/>
>
>
>
--
*Amila De Silva*
WSO2 Inc.
mobile :(+94) 775119302
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
