does not know about the PATCH http method

[deepak]

known_methods in callbacks is
['GET', 'HEAD', 'POST', 'PUT', 'DELETE', 'TRACE', 'CONNECT', 'OPTIONS']

[bethesque]

Is there any plan/schedule for PATCH to be implemented?

[seancribbs]

There are currently no plans, but I am open to proposals for how to re-adjust the FSM to handle PATCH

[tarcieri]

@seancribbs are there considerations at play that make PATCH significantly different from POST?

[seancribbs]

@tarcieri I suppose the conneg-dance would have to be done, but honestly I haven't looked too deeply into it.

[bethesque]

I understand PATCH to be more similar to PUT than POST. As a stop gap hack for my current use case, I have overridden request.put? to return true when PATCH is used, and the behaviour seems to proceed as I expect it for my use case. However, I have not yet looked deeply into the HTTP spec for PATCH to see where it differs from PUT.

[tarcieri]

Oof, my bad. Thinking about it more PATCH should be idempotent which definitely makes it different from POST

[seancribbs]

Right, my intuition is that you'd want conditional request semantics with PATCH, but also you should not accept the request if the resource doesn't exist, so it'll be mostly like PUT, but with a few changes.

[bethesque]

"If the Request-URI does not point to an existing resource, the server MAY create a new resource, depending on the patch document type (whether it can logically modify a null resource) and permissions, etc." http://tools.ietf.org/html/rfc5789

This makes sense to me - in my use case, I wanted to set one attribute on a resource, and if that resource didn't exist, I wanted it to be created. It would be annoying to have to do a GET to determine if it existed or not, and then do a PATCH - that would defeat part of the purpose of a PATCH.

And actually, reading the spec further, PATCH is not idempotent (I'd initially thought it would be). For example, you might have a PATCH request to add an item to a collection - running this twice should result in two items being added to the collection. It seems like it's something of a cross between POST and PUT. Should be interesting to implement!

[bethesque]

I've had a go at adding patch to the FSM diagram, based on my understanding of the HTTP spec - not at all confident it's right or complete, but have to start somewhere! Excuse my terrible image modification skills.

http://s886.photobucket.com/user/bethesk/media/http-headers-status-v3-with-patch_zps845e3d42.png.html

[bethesque]

Bump! Sorry to hassle you @seancribbs, but we're hoping to use webmachine as the default framework for all new microservices in our organisation, and the lack of patch is a bit of a problem for us. Happy to do the work, but would appreciate your thoughts on the state machine diagram above, as you're the expert on how it currently works. (You'll need to dig into the photobucket menu to get to the original image as it's obviously illegible at the preview resolution.)

With the changes in your diagram, the possible previous existance of the resource is taken into account, and implicit creation can only happen if the resource didn't previously exist.

We could as well keep it simpler and branch behind I7, going the same way up north if PATCH?. That's also what you already do in O7. That'd also make explaining the feature easy: PATCH behaves exactly like PUT, but instead of a new version of the resource, the request entity contains instructions on how to modify the existing resource on the server. And it's up to your resource implementation how to process these instructions.

RFC5789 suggests something very similar:

   The difference between the PUT and PATCH requests is reflected in the
   way the server processes the enclosed entity to modify the resource
   identified by the Request-URI.  In a PUT request, the enclosed entity
   is considered to be a modified version of the resource stored on the
   origin server, and the client is requesting that the stored version
   be replaced.  With PATCH, however, the enclosed entity contains a set
   of instructions describing how a resource currently residing on the
   origin server should be modified to produce a new version.

Regarding PATCH is not idempotent: it can be effectively idempotent, depending on the patch instructions. Clients just shouldn't ever blindly consider it idempotent without taking the media-type into account.

[bethesque]

Thanks for the response! Yes, I agree about PATCH being similar to put - the fact that my hack works (return true to request.put? when the method is PATCH) kind of supports that. I'll have another go at the diagram.

you should not accept the request if the resource doesn't exist

@seancribbs I think it's simpler to leave that to the resource, just as with PUT.

def content_types_accepted
  [['application/x-patch', :from_patch]]
end

def from_patch
  if resource_exists?
    apply_patch(request.body.to_s)
    response.code = 204
  else
    response.code = 404
  end
end

[bethesque]

Agreed. The HTTP spec states "the server MAY create a new resource". For my use case, I definitely wanted it to create the resource for me if it didn't exist, then apply the changes from the patch. Defeats half the purpose of using patch otherwise.