A GET on a resource returns *the* resource. All that can vary is its requested representation (i.e. as JSON, XML,... rendering). I.e. if the GET in Store and the GET in Publisher return different resources (i.e. different data structures independent from their rendering) we should have two different APIs. Thus, I agree with Jo...
Note, that this is a REST purists point of view. There are examples that provide viewing mechanisms by specifying which "fields" of a resource should be retrieved. But this results in problems like caching etc. Thus, I tend to the purists' approach. Best regards, Frank 2015-10-13 19:40 GMT+02:00 Joseph Fonseka <jos...@wso2.com>: > 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 <sanje...@wso2.com> > 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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
