Hi Huabing, 1.
We have some good experience with Itsio and would love to be part of the conversation. It's one of the things we're looking at, too, in terms of improving ONAP's currently basic containerization. We are starting by looking at OOM but hope to find best practices that could work for all projects. I think it's better to convince with a PoC rather than theory in this case, because Itsio is indeed quite new, sometimes hard to explain, but its benefits are clear when you see them in use. 3. In terms of our "RESTful" APIs -- this has been a pet peeve of mine for a long time, but I wish we would stop calling all our APIs RESTful, when in fact they are rarely RESTful in our project. They are simply "HTTP" (or "web") APIs. "CRUD" does not map very well onto REST. That said, I applaud your proposal and it has many good points. But I would like to make a few comments: I would add this emphasis: readers should pay attention to the use of POST for "create". I've seen many frameworks recommend PUT for "create", which is definitely wrong (not exactly: more on that below). POST is the only non-idempotent HTTP verb, and as such will guarantee atomicity: the resource will not be created twice, even being a proxy. However, using PUT for "update" is imprecise. Especially your comment that if the resource does not exist then PUT would return an error. Here is the description of PUT from the HTTP spec: "The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response." So, as you see, PUT is also a kind of "create". But because PUT is idempotent, you definitely don't want to support PUT on "/pets/dogs". But PUT on "/pets/dogs/bailey" should work. (Even if the request is sent several times, it would create/update the same resource, so idempotency is honored). What does it mean that there are two ways to "create" the resource? Actually, they are different. When you POST to "/pets/dogs" you do not yet know the ID of the dog. The ID would be created for you (once and only once) and returned in the response. However, in some cases you know in advance the ID of the object, in which case you should PUT to "/pets/dogs/ID". Then, you would know if it was created by checking the status code: 200 for modified or 201 for created. (Though note that it's not a good idea to functionally rely on this distinction: because PUT is idempotent, there is a chance that more than one client would get the 201 response in the case of caching proxies.) As for APIs that are not CRUD-like, it's important for the designer to think twice before using POST, because POST is the least scalable verb (it can never be cached). Ask yourself: what would happen if the API got called more than once with exactly the same request content? If the answer is "bad things", then definitely use POST. (All classic RPC-like "function calls" on web APIs should basically use POST.) For all other cases, use PUT or GET as appropriate. Finally, for your section on HTTP status codes, I would add this emphasis: make sure never to return 2XX series success codes in case of an error. I've seen APIs return 200 with an error code inside the JSON response. This makes exception handling on the client side inconsistent and can lead to bugs. If we want to do this right, I would go even further and make sure to 1) return client caching headers (maxAge, etag, etc.) with every response where appropriate, and 2) try to use HTTP clients that support client-side caching. (A good caching proxy would do it for you, too.) If we work with HTTP instead of against it we will improve the scalability and reliability of the project because all the compliant proxies/gateways/loadbalancers/caches along the way will do the right thing for us. On Tue, Mar 13, 2018 at 11:00 PM, <zhao.huab...@zte.com.cn> wrote: > Hi all, > > I'd like to share some of my thoughts about ONAP Microservice Architecture > for Casablanca and beyond > > > 1. Service Mesh > > Service Mesh is the next generation of Microservice approach, which can > bring lots of benefits to ONAP and its users at both the development and > operation sides. Such as > > - > > the separation of business logic and Microservice > infrastructure(communication, security, metrics etc) > - > > allowing free choice of development tech stack > - > > flexible route rules to enable traffic steering and canary release > - > > monitoring and tracing visibility > - > > fault injection for resiliency testing, etc > > We should take service mesh into consideration. There are multiple choices > on the table right now, given its tight relationship with kubernetes which > is used for ONAP deployment, I suggest we give Istio a shot in Casablanca. > MSB project is investigating the possibility of integration of Istio and > ONAP right now. > > > 2. Centralized Authentication > > ONAP is a huge system consisting of many services. Currently, different > services such as AAI, SDC, Policy etc. have their own authentication > process, which makes ONAP difficult to use and adds burden to the > individual project to enforce the cross-project authentication logic. We > need to consider implementing some kind of centralized authentication, > which means user login once and can access all the services. We also need > to consider how to secure the access of 3-party systems by using API token > or OAuth. > > > 3. Unified API standard > > Most of the projects produce RESTFul APIs for consuming, but in a > none-consistent way. we need to define some unified standards/best > practices on the REST API definition across the ONAP projects such > as versioning, url, error code. There is a draft in the wiki page: > https://wiki.onap.org/display/DW/RESTful+API+Design+Specification > > BR, > > Huabing > > _______________________________________________ > onap-discuss mailing list > onap-discuss@lists.onap.org > https://lists.onap.org/mailman/listinfo/onap-discuss > >
_______________________________________________ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
