additional verb support

[barneyb]

Currently requests made with the PUT, POST, and DELETE verbs all return 404, even if made against a file which exists.

It seems like POST and DELETE should return 200 for files which exist and 404 otherwise. PUT should always return 200. In all three cases, no actual operations should be performed by the server, just accept-and-ignore so that HTTP response is at least "happy path" so clients can issue mutating requests and have them succeed for the main use cases.

[simb]

We had a discussion in the past about echoing whatever was sent back to the user on anything but a get. But in the case where you want to actually end up at a particular page.

I propose there are two ways you would want to use a mock VERB and two ways you might want to respond.

1. If you are mocking an endpoint you want to communicate with via ajax then with Content-Type: application/json then:
   a. If the resource you are VERBing too exists then return it. This allows you to respond with mock json
   b. If the reource does not exist, then echo the body of the request.
2. If you are mocking a form submission to a page that should render
   a. If resource exists return that with status 200
   b. If resource does not exist return status 404

Woud that work for the scenario you are exploring?

[barneyb]

I'm pretty sure the verbs cannot be considered universally, as they have different semantics. Or at least more than one semantic across the gamut.

GET, HEAD, POST, and DELETE all must target an existing resource. Only PUT may target a non-existent resource (implying it should be created). TRACE is an anomaly in that it should be a blind echo of what is received, but is probably uninteresting for httpster (as it is designed for diagnostics and httpster will only be used when the full stack is in control of the user). Assuming current GET behaviour is fine, and that HEAD is a specialization of GET, only POST, DELETE, and PUT remain.

POST and DELETE should require targeting an existing resource to issue 200 (instead of 404). I don't think that POST to a non-existent resource should echo back the request body - that's the behaviour that PUT is supposed to embody. So I stand by my original proposal with the clarifications that POST and DELETE should return the targeted resource and that PUT should always return the passed request body (never the targeted resource).

Based on the HTTP spec, one could certainly argue that a POST to an existing resource should return 201 with a Location to the location of the new subordinate resource, but as the semantics of that are unspecified, I don't know how httpster could hope to handle it in a general way. If a dev cares about that, they need to implement the server side (or perhaps provide a suggestions on how to parameterize POST handling in httpster).