You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltacloud.apache.org by Michal Fojtik <mf...@redhat.com> on 2012/11/27 12:47:33 UTC
Updating resources
Hi,
I'm trying to figure out what would be the best way to to handle resource
updates. For example, updating an instance named [DTACLOUD-366, DTACLOUD-345].
For now, in Deltacloud we don't support the 'update' operation, however,
some clouds like FGCP (and partially OpenStack/RHEV-M/EC2) do support this
feature.
There are three possible scenarios:
1. Using 'PUT' (PUT /api/instances/inst1):
The request body will contain full representation of the resource (so
basically we will replace the old resource with a new one).
2. Using 'PATCH' (PATCH /api/instances/inst1?name=new_name):
In this case, you can choose what attributes you want to update as query
parameters. It also seems to be a more REST-friendly approach when you're
updating just a single attribute.
3. Using 'POST' (POST /api/instances/inst1/edit?name=new_name):
Basically the same thing as 2), but instead of the PATCH HTTP method, we
can use the
'POST' method on the 'edit' action. The dark side of this approach is that
we are poisioning the URL namespace with '/edit' (that is, the instance ID
can't be set to 'edit').
I known that in the CIMI, updating is done by combination of 1). and 2)
(PUT + '/edit'), which could be our option 4). However, I don't like this
approach, because PUT is meant to replace the whole resource and does not
fit well when you're updating just a single attribute.
The second part of implementing the 'update' operation is to add support
for it into drivers. I think the simpliest way is:
def update_instance(credentials, instance_id, opts={})
# safely do; driver.update_attrs(...) ;end
end
The last part is to mark what attributes are allowed for the update. I
think this will vary from one provider to another. We can both advertise
this usingthe OPTIONS method or just simply return a validation error to
the client when he tries to update a read-only attribute. (Or we can use
the database to store them....)
My personal preference is 2) :-), but I just want to start a discussion
about this before somebody starts writing the code (I know that there are
milions of blogs/articles about updating resources, the problem is what to
choose and what will fit to us ;-)
Cheers,
-- Michal
--
Michal Fojtik <mf...@redhat.com>
Deltacloud API, CloudForms
Re: Updating resources
Posted by Michal Fojtik <mf...@redhat.com>.
On 11/27, Florin Ardelian wrote:
> Can you explain why the instance ID can't be set to 'edit' in this case?
My mistake, sorry. Of course instance can be set to 'edit', in that case the
url will be 'POST /api/instances/edit/edit'.
>
> On Tue, Nov 27, 2012 at 1:47 PM, Michal Fojtik <mf...@redhat.com> wrote:
>
> > 3. Using 'POST' (POST /api/instances/inst1/edit?name=new_name):
> >
> > Basically the same thing as 2), but instead of the PATCH HTTP method, we
> > can use the
> >
> > 'POST' method on the 'edit' action. The dark side of this approach is that
> > we are poisioning the URL namespace with '/edit' (that is, the instance ID
> > can't be set to 'edit').
> >
>
> --
> Florin
> +40-740-903838
--
Michal Fojtik <mf...@redhat.com>
Deltacloud API, CloudForms
Re: Updating resources
Posted by Florin Ardelian <f....@gmail.com>.
Can you explain why the instance ID can't be set to 'edit' in this case?
On Tue, Nov 27, 2012 at 1:47 PM, Michal Fojtik <mf...@redhat.com> wrote:
> 3. Using 'POST' (POST /api/instances/inst1/edit?name=new_name):
>
> Basically the same thing as 2), but instead of the PATCH HTTP method, we
> can use the
>
> 'POST' method on the 'edit' action. The dark side of this approach is that
> we are poisioning the URL namespace with '/edit' (that is, the instance ID
> can't be set to 'edit').
>
--
Florin
+40-740-903838
Re: Updating resources
Posted by David Lutterkort <lu...@redhat.com>.
Hi Michal,
yes, these are all good questions; just to add to the options: there's
also a door #4: PATCH edit instructions to the resource's URL.
I find #1 very problematic, since it seems too easy to make disastrous
mistakes and way too chatty; for #2 and #3, I'd rather not continue
relying too much on request parameters, I think we already overuse them
in the DC API
There's a draft for a JSON format for editing resources[1] - while the
full thing seems overkill, I like how doing this very precisely
specifies what changes you want. It's also fairly friendly for clients,
as they can build one of these objects up as their user is making
changes.
For example, to change the name of an instance, you'd do
PATCH /api/instances/inst0
[
{ "op": "replace", "path": "/name", "value": "new_name" }
]
David
[1] http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-06
On Tue, 2012-11-27 at 12:47 +0100, Michal Fojtik wrote:
> Hi,
>
> I'm trying to figure out what would be the best way to to handle resource
> updates. For example, updating an instance named [DTACLOUD-366, DTACLOUD-345].
> For now, in Deltacloud we don't support the 'update' operation, however,
> some clouds like FGCP (and partially OpenStack/RHEV-M/EC2) do support this
> feature.
>
> There are three possible scenarios:
>
> 1. Using 'PUT' (PUT /api/instances/inst1):
>
> The request body will contain full representation of the resource (so
> basically we will replace the old resource with a new one).
>
> 2. Using 'PATCH' (PATCH /api/instances/inst1?name=new_name):
>
> In this case, you can choose what attributes you want to update as query
> parameters. It also seems to be a more REST-friendly approach when you're
> updating just a single attribute.
>
> 3. Using 'POST' (POST /api/instances/inst1/edit?name=new_name):
>
> Basically the same thing as 2), but instead of the PATCH HTTP method, we
> can use the
>
> 'POST' method on the 'edit' action. The dark side of this approach is that
> we are poisioning the URL namespace with '/edit' (that is, the instance ID
> can't be set to 'edit').
>
> I known that in the CIMI, updating is done by combination of 1). and 2)
> (PUT + '/edit'), which could be our option 4). However, I don't like this
> approach, because PUT is meant to replace the whole resource and does not
> fit well when you're updating just a single attribute.
>
> The second part of implementing the 'update' operation is to add support
> for it into drivers. I think the simpliest way is:
>
> def update_instance(credentials, instance_id, opts={})
> # safely do; driver.update_attrs(...) ;end
> end
>
> The last part is to mark what attributes are allowed for the update. I
> think this will vary from one provider to another. We can both advertise
> this usingthe OPTIONS method or just simply return a validation error to
> the client when he tries to update a read-only attribute. (Or we can use
> the database to store them....)
>
> My personal preference is 2) :-), but I just want to start a discussion
> about this before somebody starts writing the code (I know that there are
> milions of blogs/articles about updating resources, the problem is what to
> choose and what will fit to us ;-)
>
> Cheers,
>
> -- Michal
>
Re: Updating resources
Posted by Florin Ardelian <f....@gmail.com>.
Number 2 (PATCH /api/instances/inst1?name=new_name) sounds good to me, too.
On Tue, Nov 27, 2012 at 1:47 PM, Michal Fojtik <mf...@redhat.com> wrote:
> Hi,
>
> I'm trying to figure out what would be the best way to to handle resource
> updates. For example, updating an instance named [DTACLOUD-366,
> DTACLOUD-345].
> For now, in Deltacloud we don't support the 'update' operation, however,
> some clouds like FGCP (and partially OpenStack/RHEV-M/EC2) do support this
> feature.
>
> There are three possible scenarios:
>
> 1. Using 'PUT' (PUT /api/instances/inst1):
>
> The request body will contain full representation of the resource (so
> basically we will replace the old resource with a new one).
>
> 2. Using 'PATCH' (PATCH /api/instances/inst1?name=new_name):
>
> In this case, you can choose what attributes you want to update as query
> parameters. It also seems to be a more REST-friendly approach when you're
> updating just a single attribute.
>
> 3. Using 'POST' (POST /api/instances/inst1/edit?name=new_name):
>
> Basically the same thing as 2), but instead of the PATCH HTTP method, we
> can use the
>
> 'POST' method on the 'edit' action. The dark side of this approach is that
> we are poisioning the URL namespace with '/edit' (that is, the instance ID
> can't be set to 'edit').
>
> I known that in the CIMI, updating is done by combination of 1). and 2)
> (PUT + '/edit'), which could be our option 4). However, I don't like this
> approach, because PUT is meant to replace the whole resource and does not
> fit well when you're updating just a single attribute.
>
> The second part of implementing the 'update' operation is to add support
> for it into drivers. I think the simpliest way is:
>
> def update_instance(credentials, instance_id, opts={})
> # safely do; driver.update_attrs(...) ;end
> end
>
> The last part is to mark what attributes are allowed for the update. I
> think this will vary from one provider to another. We can both advertise
> this usingthe OPTIONS method or just simply return a validation error to
> the client when he tries to update a read-only attribute. (Or we can use
> the database to store them....)
>
> My personal preference is 2) :-), but I just want to start a discussion
> about this before somebody starts writing the code (I know that there are
> milions of blogs/articles about updating resources, the problem is what to
> choose and what will fit to us ;-)
>
> Cheers,
>
> -- Michal
>
> --
> Michal Fojtik <mf...@redhat.com>
> Deltacloud API, CloudForms
>
--
Florin
+40-740-903838
Re: Updating resources
Posted by Doug Davis <du...@us.ibm.com>.
CIMI isn't quite as you described. CIMI uses a query parameter ($select)
to indicate which subset of the resource to act upon. The query parameter
doesn't contain the new value. By subsetting the resource the URL is now
referencing a different resource and then a full PUT is done on that
resource, so it's fully HTTP compliant. What's nice about this approach,
to me anyway in my testing, is that if you process the $select first and
have the code get back a 'new' resource, the rest of your PUT code can
behave like normal, nothing special is needed, just do a full PUT.
My concern with putting values into a URL is that you're limited in what
you can put there, either by size or just annoyance because you have to
escape stuff.
-Doug
On Nov 27, 2012, at 6:48 AM, "Michal Fojtik" <mf...@redhat.com> wrote:
> Hi,
>
> I'm trying to figure out what would be the best way to to handle resource
> updates. For example, updating an instance named [DTACLOUD-366,
DTACLOUD-345].
> For now, in Deltacloud we don't support the 'update' operation, however,
> some clouds like FGCP (and partially OpenStack/RHEV-M/EC2) do support
this
> feature.
>
> There are three possible scenarios:
>
> 1. Using 'PUT' (PUT /api/instances/inst1):
>
> The request body will contain full representation of the resource (so
> basically we will replace the old resource with a new one).
>
> 2. Using 'PATCH' (PATCH /api/instances/inst1?name=new_name):
>
> In this case, you can choose what attributes you want to update as query
> parameters. It also seems to be a more REST-friendly approach when you're
> updating just a single attribute.
>
> 3. Using 'POST' (POST /api/instances/inst1/edit?name=new_name):
>
> Basically the same thing as 2), but instead of the PATCH HTTP method, we
> can use the
>
> 'POST' method on the 'edit' action. The dark side of this approach is
that
> we are poisioning the URL namespace with '/edit' (that is, the instance
ID
> can't be set to 'edit').
>
> I known that in the CIMI, updating is done by combination of 1). and 2)
> (PUT + '/edit'), which could be our option 4). However, I don't like this
> approach, because PUT is meant to replace the whole resource and does not
> fit well when you're updating just a single attribute.
>
> The second part of implementing the 'update' operation is to add support
> for it into drivers. I think the simpliest way is:
>
> def update_instance(credentials, instance_id, opts={})
> # safely do; driver.update_attrs(...) ;end
> end
>
> The last part is to mark what attributes are allowed for the update. I
> think this will vary from one provider to another. We can both advertise
> this usingthe OPTIONS method or just simply return a validation error to
> the client when he tries to update a read-only attribute. (Or we can use
> the database to store them....)
>
> My personal preference is 2) :-), but I just want to start a discussion
> about this before somebody starts writing the code (I know that there are
> milions of blogs/articles about updating resources, the problem is what
to
> choose and what will fit to us ;-)
>
> Cheers,
>
> -- Michal
>
> --
> Michal Fojtik <mf...@redhat.com>
> Deltacloud API, CloudForms
>