3 ms·

Why? What's the actual problem with using PUT for idempotent partial updates?

• pfraze 14y ago
  Consistency. You're entitled to break verb conventions, but you may confuse newcomers or force API consumers to special-case for you.
  • glenjamin 14y ago
    As a server receiving a PUT request that does not contain all of the fields on your resource, your options for handling the response are: 1. 400 bad data - a failed request 2. Blank out / delete the values of all fields not specified 3. Perform a PATCH-style partial update Which of these is the most useful / least surprising / closest to the spec? Now read the spec: http://tools.ietf.org/html/rfc2616#section-9.6 http://tools.ietf.org/html/rfc2616#section-9.6 PUT should store the request as the resource, it doesn't have to. Also note the complete absence of push from the precious specification! (I know patch is an amendment, my point us that the HTTP spec shouldn't be considered perfect)
    • pfraze 14y ago
      If my PUT passes validation, I'd expect the resource to be overwritten with my request body (#2). If it doesn't, 400 (#1). If I do a PATCH, I'd expect #3. If PUT falls back to PATCH, then there's no replace action, which might be useful. It doesn't end up being a huge deal practically, because partial updates are probably more common than replaces, but that's my reasoning for it.