AFAIU, It will be better to have two separate object model for both store and publisher.
*Dhanuka Ranasinghe* Associate TechLead WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 715381915 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 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/> > > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
