Open Stack

As you said RESTful is not a standard but brings guidelines of good 
practices. Which in turn doesn't preclude adding ideas, as long as 
respecting RESTful approach. So we get from both sides.

Therefore a good schema structure adds to a de-facto standard, once the 
practice is commonly used.


On 02/02/18 19:11, Duncan Thomas wrote:
> So I guess my question here is why is being RESTful good? Sure it's 
> (very, very loosely) a standard, but what are the actual advantages? 
> Standards come and go, what we want most of all is a good quality, 
> easy to use API.
>
> I'm not saying that going RESTful is wrong, but I don't see much 
> discussion about what the advantages are, only about how close we are 
> to implementing it.
>
> On 1 Feb 2018 10:55 pm, "Ed Leafe" <ed at leafe.com 
> <mailto:ed at leafe.com>> wrote:
>
>     On Jan 18, 2018, at 4:07 AM, TommyLike Hu <tommylikehu at gmail.com
>     <mailto:tommylikehu at gmail.com>> wrote:
>
>     >    Recently We found an issue related to our OpenStack action
>     APIs. We usually expose our OpenStack APIs by registering them to
>     our API Gateway (for instance Kong [1]), but it becomes very
>     difficult when regarding to action APIs. We can not register and
>     control them seperately because them all share the same request
>     url which will be used as the identity in the gateway service, not
>     say rate limiting and other advanced gateway features, take a look
>     at the basic resources in OpenStack
>
>     We discussed your email at today’s API-SIG meeting [0]. This is an
>     area that is always contentious in the RESTful world. Actions,
>     tasks, and state changes are not actual resources, and in a pure
>     REST design they should never be part of the URL. Instead, you
>     should POST to the actual resource, with the desired action in the
>     body. So in your example:
>
>     > URL:/volumes/{volume_id}/action
>     > BODY:{'extend':{}}
>
>     the preferred way of achieving this is:
>
>     URL: POST /volumes/{volume_id}
>     BODY: {‘action’: ‘extend’, ‘params’: {}}
>
>     The handler for the POST action should inspect the body, and call
>     the appropriate method.
>
>     Having said that, we realize that a lot of OpenStack services have
>     adopted the more RPC-like approach that you’ve outlined. So while
>     we strongly recommend a standard RESTful approach, if you have
>     already released an RPC-like API, our advice is:
>
>     a) avoid having every possible verb in the URL. In other words,
>     don’t use:
>       /volumes/{volume_id}/mount
>       /volumes/{volume_id}/umount
>       /volumes/{volume_id}/extend
>     This moves you further into RPC-land, and will make updating your
>     API to a more RESTful design more difficult.
>
>     b) choose a standard term for the item in the URL. In other words,
>     always use ‘action’ or ‘task’ or whatever else you have adopted.
>     Don’t mix terminology. Then pass the action to perform, along with
>     any parameters in the body. This will make it easier to transition
>     to a RESTful design by later updating the handlers to first
>     inspect the BODY instead of relying upon the URL to determine what
>     action to perform.
>
>     You might also want to contact the Kong developers to see if there
>     is a way to work with a RESTful API design.
>
>     -- Ed Leafe
>
>     [0]
>     http://eavesdrop.openstack.org/meetings/api_sig/2018/api_sig.2018-02-01-16.02.log.html#l-28
>     <http://eavesdrop.openstack.org/meetings/api_sig/2018/api_sig.2018-02-01-16.02.log.html#l-28>
>
>
>
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180205/daad66fe/attachment.html>