COmanage Developers List

[Marie Huynh <>]

I tested using curl.  In short:

	return	method	URL	existing	affects data	note
	edit
	200	PUT	/cous/567.json	yes	y	does not overwrite fields not specified
	404	PUT	/cous/567000.json	no	n
	200	POST	/cous/567.json	yes	y	does not overwrite fields not specified
	404	POST	/cous/567000.json	no	n
	add
	201	POST	/cous.json	no	y
	500	POST	/cous.json	yes	n
		PUT	/cous.json	no	n	treated like GET(view all)
		PUT	/cous.json	yes	n	treated like GET(view all)

As far as I can tell, editing via PUT and POST does the same thing and neither overwrites the whole existing node and disabling POST should be fine.  I can do that in cake/libs/router.php but I haven't figured out how to do it in routes.php yet.


Marie

On Thu, Oct 20, 2011 at 12:53 PM, Scott Koranda <> wrote:
>> Bringing this back to -dev since Scott started this thread originally...

>>
>> Out of the box, Cake will map POST to add() and POST or PUT to edit,
>> depending on the URL format. So to make the switch described in the
>> ticket, I'm not sure we actually need to change anything

>> technically, just the documentation. (There wasn't any particular
>> reason I started with POST instead of PUT.)
>>
>> So, should we?
>>
>> Well, if we follow the guide described in wikipedia

>>
>>
>> http://en.wikipedia.org/wiki/Representational_State_Transfer#RESTful_web_services
>>

>> the answer is yes, since PUT on an element replaces it, whereas POST
>> on an element creates a new entry under the existing one.
>>
>> Another metric is idempotency (PUT is, POST isn't). In general, our

>> edit operations are idempotent (and if they aren't perhaps they
>> shouldn't be 'edit' operations), and so by this standard the answer
>> is also yes.
>>
>> So I'd suggest

>>
>> (1) We update the documentation so all edit operations are PUT
>> (2) We verify that all update operations are in fact idempotent
>> (3) We test to make sure PUT requests are handled correctly

>> (4) We disable POST for edits
>>
>> Thoughts?
>
> +1
>
> Scott
>
>