How to edit a resource?

tags:

rest

views:

answers:

How to edit a resource?

+2 A:

The URL always represents the resource, not the action. Thus, while mysite/resource_one/edit might be a proper URL to a page that initiates editing a resource, it's not a part of the REST API itself, it's part of the web app that uses that REST API to manipulate that resource. Moreover, in that example mysite/resource_one would be a confusing representation of the resource.

To create a new resource, you use POST on the parent resource, with the body of the request containing the data for the new resource. The response contains the URL for the newly created resource.

To update an existing resource, you use PUT on the resource URL, with the body of the request containing either full or partial update of the resource data.

Franci Penov 2010-08-08 01:09:49

Actually, to my understanding PUT both creates and deletes. It is about an action being idempotent or not. In the case of mysite/articles you would use POST because the action is **not** idempotent. If you run that POST request on that resource 10 times, you get 10 resources. However, if you know the url, Ie, in a wiki: mysite/some_resource_name, you want to PUT the request because even if you create it 10 times, only the first creation is used. Same goes for editing, PUT is used to edit because it is idempotent.POST is not idempotent, GET/PUT/DELETE are. At least, that is my understanding :)

Lee Olayvar 2010-08-08 15:11:04

But back to the topic. Yea i guess i see your point. I mean, i don't see any other way to do it than to use mysite/resource_one/edit, but it just seems odd to me. Technically i guess the edit itself *is* a resource, rather than an action. In your opinion then, when you edit the resource, where does the action go? mysite/resource_one or mysite/resource_one/edit?

Lee Olayvar 2010-08-08 15:14:29

Another reason to dislike resource/edit, is simply because it is not standardized.. to my knowledge. I believe a big part of REST is simply to create services that have little application specific usage. Ie, if you use delete on a resource you delete it. All services should have that in common. If you get a resource, you get it. And so on. But what about editing and creating? We know what methods to use on them, but now how to let the service tell us what data it wants. Eg, resource/edit, resources/new, etc. That seems to not be standardized (well, that's what i am asking here) :/

Lee Olayvar 2010-08-08 15:29:18

No, `PUT` does not delete, and while it can be (and is) used to create, this is incorrect implementation, as per the HTTP RFC.

Franci Penov 2010-08-09 03:27:46

Your mistake is that you are mixing the API to manipulate the resources and the web app that edits the resources data. The web app provides the user experience around adding new resources or editing existing resource, including editors and visualizers. The API is used to translate the resources data between the client and the server.A well designed API will allow multiple editors to manipulate the resources. This means that editing the resource can be potentially done from multiple different URLs or even a client app.

Franci Penov 2010-08-09 03:50:07

Meanwhile, from API's PPOv, there's no such thing as `edit` action - there's `create` new resource, and `read`, `update`, `delete` existing resources. The URL on which the first one is performed is the parent resource, the rest are performed on the resource itself. But the URL is always the object of the manipulation, it's never the action itself.

Franci Penov 2010-08-09 03:52:03

I never said (or ment) that PUT can delete. While i see your point on the API vs frontend layer.. how is this actually implemented with a website? I mean, the frontend client layer, in this case, **cannot** properly communicate with the API as intended due to it's lack of PUT and DELETE.

Lee Olayvar 2010-08-09 12:08:55

Even if you ignore that though, how does an API (server) tell the client **how** to modify a resource? Eg, say you're a client looking to interact with a server resource. How do you know what variables in the PUT request that the server will want? Eg, we know that the server wants a PUT request.. but how is it formed? is there a name variable? Is there a body variable? etc. As far as the edit action.. same thing as update, just different terminology, my bad :o

Lee Olayvar 2010-08-09 12:12:01

Now in regards to PUT being used to create, do you have anything that says it cannot? My understanding was that the verbs simply come down to idempotence. When i get home i'll try and dig through the RFC, but it seems odd to me that to submit a resource you are required to go through a parent resource, by the spec at least. Another way to look at it, is that if the spec forces you to go through the parent resource, then you can **never create by idempotence!** This seems like a huge lack of functionality in my opinion.

Lee Olayvar 2010-08-09 12:16:23

Yes, you can never create by idempotence. The reason for this is that create requires a new identity (URL) to be generated. The IDs uniqueness can be guaranteed only by the server, thus for every create request the client has to first ask for a new ID from the server. But, when you ask the server for a new ID, for all intents and purposes, you _are creating_ the new resource (as empty). And since at the time of this reques you don't know the resource URL yet, you can only make the request to the container.

Franci Penov 2010-08-09 16:26:48

PUT on the other hand (as per RFC) requires the request to be made to the URL of the resource. And since by the time you have the URL to make the PUT request, you have already created the resource, PUT can be used only for updating existing resource.

Franci Penov 2010-08-09 16:28:28

Pardon my ignorance, but isn't requesting a GET on a non-existing resource going to tell you if the resource exists or not? And if the server sees it does not exist, it can give you the opportunity to create it? At this point the resource id is known, and a put request is still possible.I guess my main source of confusion comes from the backend vs frontend issue. Eg, if you visit mysite/resource and it doesn't exist, the server can still return a creation page on that same url.

Lee Olayvar 2010-08-10 01:38:37

In the end you have given me a lot to think about, and i thank you for that! I need to research a lot to figure out what is what heh. I have read what feels like dozens of different views of how REST operates. It's driving me nuts.. If you know the URL for the spec i would be **much** appreciated! I cannot comprehend how so many different views exist on something which has a spec :(.. perhaps the spec is wrote very poorly/confusing heh.

Lee Olayvar 2010-08-10 01:41:14

there's no REST spec. The PUT and POST semantic is defined in the HTTP RFC.

Franci Penov 2010-08-10 04:04:29

Assume for a moment that we have a shared address book webapp, where create is idempotent operation made on the resource URL and if the resource does exists, it changes to update, and URLs are the person SSN. There's no record for me, and two users want to add one. User 1 makes new record for me using my full name - Francislav, user 2 makes at the same time my short name - Franci. They click on the Click on the submit button at the same time. what's my name in the newly created record? The only way to avoid conflict is to make create fail if resource exists, but that makes it not idempotent.

Franci Penov 2010-08-10 04:22:11

How does creation failing if the resource exists make it not idempotent? Deletion fails if the resource does not exist, correct? I thought that was the definition of idempotent. The action can only be preformed once, and any subsequent attempts result in failures or nothing, just like GET.. depending on how the server likes to handle additional idempotent calls. *(I really appreciate this conversation, and i am simply debating to understand. Just to make it clear that i am not arguing against your points :))*

Lee Olayvar 2010-08-10 12:08:54

The definition of idempotence is slightly different - an operation is idempotent only if it results in the same outcome when repeated. You can hardly argue that a failure is the same outcome as a success.

Franci Penov 2010-08-10 17:08:51

Meanwhile, DELETE is idempotent only if the server responds with success on delete of a non-existing resource. And with regards to delete semantic, not failing it is absolutely acceptable - the client's purpose of that resource being non-existent is successfully fulfilled (same as deleting a NULL pointer being a successful operation).

Franci Penov 2010-08-10 17:09:30

The same outcome when repeated is odd to me. What you're saying is that idempotence is based off of the client, rather than the server. In other words, for an action to be idempotent you're saying the server has to return the same result every time. But, on the server side, the action **is** idempotent, because no matter how many times the client sends the action, the server only changes it once. So i'm confused on that front.

Lee Olayvar 2010-08-11 01:27:50

Lee Olayvar 2010-08-11 01:33:10

Lol, feel free to send me an email and we can continue the discussion there. :-)

Franci Penov 2010-08-11 03:57:07

ansaurus

tags:

views:

answers:

How to edit a resource?

related questions