Sounds good! I will edit it and try to be succinct. On Wed, Mar 14, 2018 at 3:26 AM, <[email protected]> wrote:
> Hi Tal, > > Good points. > > 1. > > You're right, Istio is still not production ready while service mesh > approach is very promising, We're trying to set up a demo with ONAP to > demonstrate its benefits. > 2. > > I agree that most of the APIs we have now are not "REST", actually > sometimes it's difficult to make the HTTP APIs "100%" REST, but we still > need a standard for all the "HTTP" or "REST-like" APIs to make the APIs > more friendly for the ONAP developers and users. Just feel free to edit the > wiki page, it's an input for improvement:-). > > BR, > > Huabing > 原始邮件 > *发件人：*TalLiron <[email protected]> > *收件人：*[email protected] <[email protected]> > *日 期 ：*2018年03月14日 14:06 > *主 题 ：**Re: [onap-discuss] Some thoughts about ONAP > MicroserviceArchitecture for Casablanca and beyond: Service > Mesh,Centralized Authentication and unified API standards* > _______________________________________________ > onap-discuss mailing list > [email protected] > https://lists.onap.org/mailman/listinfo/onap-discuss > > 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, <[email protected]> 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 >> [email protected] >> https://lists.onap.org/mailman/listinfo/onap-discuss >> >> > >
_______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
