Hi Sanjeewa, I assume Store and Publisher share the same database although they will offer different APIs, correct? In that case, a common data model is the preferred way.
Best regards, Frank 2015-10-14 8:25 GMT+02:00 Sanjeewa Malalgoda <[email protected]>: > Thanks Frank ,Amila, Harshana, Jo, Dhanuka for your valuable inputs. > So it seems all are agree on having 2 different APIs/web services for > store and publisher. > > @Frank,Jo, actually store and publisher should return tow different data > associated with APIs. > But if need we can have common data model and fill only required fields in > service layer. > As example API model contains both back end url and gateway url. But store > will return object only with gateway url while publisher returns back end > url. > Since we all agreed on two different services(store and publisher APIs) > shall we conclude on data model as well. > Do we need to have common model shared with both store,publisher and > refine parameters at service layer implementation? Or have two different > data models? > > @Amila, yes core implementation and internal data representation will not > change due to this. > Only change is REST API implementation. And all duplicates will exist only > in REST API layer. > > Thanks, > sanjeewa. > > > > > On Wed, Oct 14, 2015 at 7:10 AM, Amila De Silva <[email protected]> wrote: > >> 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 >> >> > > > -- > > *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
