4 ms·

ARGH! PATCH is for partial updates, not PUT!

ajross 15y ago
Does this really rise to the level of an "ARGH!"? I mean, look: REST is nice because it simplifies front end network APIs that were getting out of hand. That is its value. Replacing the nonsense of SOAP and XML-RPC with equally ridiculous pedantry about HTTP minutiae is not helping your cause nor your software.
- tvon 15y ago
  There are all of nine HTTP methods, using them correctly should not be that difficult. edit: Well, ajross has a point. There are actually all of eight HTTP 1.1 methods, and PATCH is not one of them.
  - ajross 15y ago
    The cargo-cult fallacy that there is a "correct" way to do something as complicated and varied as web service provision is exactly the kind of nonsense I'm talking about. It is "easy" to blindly follow any rule. In most cases it is also wrong.
    - tvon 15y ago
      I'm talking about the correct way to use a HTTP method as defined by the HTTP specification. > It is "easy" to blindly follow any rule. In most cases it is also wrong. Come on.
      - ajross 15y ago
        Then you are speaking from ignorance. PATCH is not part of the HTTP specification. It's defined in an IETF RFC (5789) upon which the ink is not yet dry (March 2010, and in fact it's not even stable: the most recent errata was 31 days ago). Feeling entitled to making firm pronouncements about "correct" behavior on subjects one is not an expert in (and let's be clear: no one is an expert on PATCH yet) is in some sense the very definition of "cargo cult mentality". Edit: that's probably harsher than it's intended. My point isn't really about PATCH, which seems sane. It's about the pedantic mentality which is running rampant in the REST community (c.f. the "ARGH!" above), which in my mind is taking a good idea and polluting it with terrible nonsense in the pursuit of "purity". Think of what happened to Agile if you continue down this path.
        tvon 15y ago
        Well shit, my mistake.
        grabastic 15y ago
        Great edit. I was starting to wonder what all the opposition to PATCH was about.
    - superasn 15y ago
      Also how do you make a PUT or PATCH request from programming languages like Actionscript (and quite possibly Javascript though I'm not sure) which only support POST and GET requests currently?
      - grabastic 15y ago
        Many frameworks overload the POST operation and allow the desired verb to be specified in the data. Rack::MethodOverride does this for Rack-based apps by using the value of the _method parameter as the http verb.
      - alexchamberlain 15y ago
        FYI Javascript supports PUT. I suppose firewalls could be a problem...
    - pfraze 15y ago
      There is a good reason to adhere to common usage for the common verbs, though: you can meet expectations better. We generally know what to expect out of GET because it's used consistently.
- alexchamberlain 15y ago
  As someone else said, the API is the UI for the developer. It should be as intuitive and straight forward as possible. I would expect PUT to replace a resource at a specific URL and POST to create a resource under a URL. Therefore, to do a partial update, we need a new verb. Having said that, I like subresource URLs and using PUT to do partial updates like that.
voyou 15y ago
Why? What's the actual problem with using PUT for idempotent partial updates?
- pfraze 15y ago
  Consistency. You're entitled to break verb conventions, but you may confuse newcomers or force API consumers to special-case for you.
  - glenjamin 15y 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 15y 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.

Does this really rise to the level of an "ARGH!"? I mean, look: REST is nice because it simplifies front end network APIs that were getting out of hand. That is its value. Replacing the nonsense of SOAP and XML-RPC with equally ridiculous pedantry about HTTP minutiae is not helping your cause nor your software.

tvon 15y ago
There are all of nine HTTP methods, using them correctly should not be that difficult. edit: Well, ajross has a point. There are actually all of eight HTTP 1.1 methods, and PATCH is not one of them.
- ajross 15y ago
  The cargo-cult fallacy that there is a "correct" way to do something as complicated and varied as web service provision is exactly the kind of nonsense I'm talking about. It is "easy" to blindly follow any rule. In most cases it is also wrong.
  - tvon 15y ago
    I'm talking about the correct way to use a HTTP method as defined by the HTTP specification. > It is "easy" to blindly follow any rule. In most cases it is also wrong. Come on.
    - ajross 15y ago
      Then you are speaking from ignorance. PATCH is not part of the HTTP specification. It's defined in an IETF RFC (5789) upon which the ink is not yet dry (March 2010, and in fact it's not even stable: the most recent errata was 31 days ago). Feeling entitled to making firm pronouncements about "correct" behavior on subjects one is not an expert in (and let's be clear: no one is an expert on PATCH yet) is in some sense the very definition of "cargo cult mentality". Edit: that's probably harsher than it's intended. My point isn't really about PATCH, which seems sane. It's about the pedantic mentality which is running rampant in the REST community (c.f. the "ARGH!" above), which in my mind is taking a good idea and polluting it with terrible nonsense in the pursuit of "purity". Think of what happened to Agile if you continue down this path.
      - tvon 15y ago
        Well shit, my mistake.
      - grabastic 15y ago
        Great edit. I was starting to wonder what all the opposition to PATCH was about.
  - superasn 15y ago
    Also how do you make a PUT or PATCH request from programming languages like Actionscript (and quite possibly Javascript though I'm not sure) which only support POST and GET requests currently?
    - grabastic 15y ago
      Many frameworks overload the POST operation and allow the desired verb to be specified in the data. Rack::MethodOverride does this for Rack-based apps by using the value of the _method parameter as the http verb.
    - alexchamberlain 15y ago
      FYI Javascript supports PUT. I suppose firewalls could be a problem...
  - pfraze 15y ago
    There is a good reason to adhere to common usage for the common verbs, though: you can meet expectations better. We generally know what to expect out of GET because it's used consistently.
alexchamberlain 15y ago
As someone else said, the API is the UI for the developer. It should be as intuitive and straight forward as possible. I would expect PUT to replace a resource at a specific URL and POST to create a resource under a URL. Therefore, to do a partial update, we need a new verb. Having said that, I like subresource URLs and using PUT to do partial updates like that.

voyou 15y ago

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

pfraze 15y ago
Consistency. You're entitled to break verb conventions, but you may confuse newcomers or force API consumers to special-case for you.
- glenjamin 15y 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 15y 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.