Hi Sanjeewa, I think in terms of flexibility, cleanliness and manageability, option 1 is better.
It gives you more control over the deployments. For example, not all deployments are completely distributed and some of them may contain components combined together (e.g: Gateway + Store in same JVM). In that case with the approach 2, we have to modify the web-app but with Approach 1 it is easy as deleting the Publisher App and the Rest API App for Publisher. So approach 1 makes the life easy for everyone. Therefore +1 for approach 1. Thanks and Regards, Harshana -- Harshana Eranga Martin Committer - Eclipse ECF: http://www.eclipse.org/ecf/ Blog: http://harshana05.blogspot.com Profile: https://www.google.com/profiles/harshana05 On 14 October 2015 at 01:40, Joseph Fonseka <[email protected]> wrote: > IMHO There should be two API definitions for Store and publisher APIs. > Mainly because even though publisher and store share some resources there > properties generally will be different e.g. data models, permissions. So > managing this in one web app will be difficult and hard to maintain. > > So +1 for two web apps namely api#am#store#v1.war and > api#am#publisher#v1.war. > > Cheers > Jo > > 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/> >> >> >> > > > -- > > -- > *Joseph Fonseka* > WSO2 Inc.; http://wso2.com > lean.enterprise.middleware > > mobile: +94 772 512 430 > skype: jpfonseka > > * <http://lk.linkedin.com/in/rumeshbandara>* > > > _______________________________________________ > 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
