You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not sure if it's the right way to handle PUT request but with the following code neither the to_json method nor the process_post is called with a PUT request:
That path looks correct.process_post should definitely not be called on a PUT. It should call content_types_accepted at v3o14, and then call the appropriate handler, which in your example will do nothing and indicate success. In the accepted handlers, it's up to the user to generate a body if appropriate. Webmachine won't generate a response automatically via content_types_provided.
Not a problem! Happy to see somebody interested in the project.
This behavior confused me a bit when I ported the library as well. The rationale for this behavior, at least for a PUT, is that the representation that was just pushed to the server would be the same one the server would return. For POST, not much is said about its response body in the spec, mostly because it can affect many different resources; the resource that process_post is the resource that handles the request, but that doesn't necessary limit the scope of its effects.
I'm not sure if it's the right way to handle PUT request but with the following code neither the
to_json
method nor theprocess_post
is called with a PUT request:The states path is:
v3b13, v3b12, v3b11, v3b10, v3b9, v3b8, v3b7, v3b6, v3b5, v3b4, v3b3, v3c3, v3c4, v3d4, v3d5, v3e5, v3f6, v3f7, v3g7, v3g8, v3h10, v3i12, v3l13, v3m16, v3n16, v3o16, v3o14, v3p11, v3o20
The text was updated successfully, but these errors were encountered: