Hi Huabing,


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.


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

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

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

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

Reply via email to