1

For example:

https://developers.facebook.com/docs/graph-api/reference/v2.1/page/locations

Coming from a Rails/REST background, I was under the impression using PUT or PATCH for updates was best practice. So I'm wondering, why did Facebook just use POST for updates?

Is it because it's just simpler to have POST and GET, rather than 4 or 5 different HTTP methods? Or is it because they're supporting some devices that only have those? Or are they planning to move to using PUT/PATCH? Any ideas?

It seems nice to use just POST for both creating and updating records, so you don't have to care about the implementation, but wondering what the reason is behind this.

Lance
  • 75,200
  • 93
  • 289
  • 503
  • See http://stackoverflow.com/questions/630453/put-vs-post-in-rest – DanMan Aug 19 '14 at 20:12
  • 1
    @DanMan your link gives the general idea around `POST/PUT/PATCH` but it think the question is more about "why did they choose POST when 'everyone' says to use PUT or PATCH". At least I would like to get inputs on that. – maxdec Sep 01 '14 at 13:01

1 Answers1

0

They don't use PUT or PATCH, because the URL does not point to the actual location of the specific item, but the whole collection. The actual ID (primary key, if you want) of the item is part of the message body.

In the FB example it seems that page-id, main_page_id, store_number and location_page_id are all required to identify the resource. page-idis already there, but in order to use PUT, they would have had to put the others in the URL as well:

PUT /v2.1/{page-id}/locations/{main_page_id}/{store_number}/{location_page}

For some reason, they didn't want to go that way. So it got ugly, since they mix the payload of the item with it's address. Generally speaking, one expects the content of the message body to contain the changes made to the resource at the address the URL is pointing to. An item's ID is the address and thus immutable, so it doesn't belong in the body.

DanMan
  • 11,323
  • 4
  • 40
  • 61