Because the test deletes the resource, the initial get should return …

[swalker-]

…a 404 - Not Found. Similarly, the final get should return a 404

[KevinLiddle]

I'm not sure if this is accurate or not. Generally I would think a DELETE is called on a route with a unique identifier (e.g. /posts/3) but I don't know what should happen if it's a generic route. I wouldn't think the /form route would go away, unless it was a file on the filesystem or something.

[swalker-]

Well, if it is intended to be a generic route, why doesn't it PUT to 'form/#'? Form is never defined in the public folder either so I assume that the first POST creates the resource - in which case the initial get should return a 404, delete should remove the resource, and the final get should return a 404.

[KevinLiddle]

After some refreshers on HTTP, I don't think your changes are necessary, or that they are technically correct. If you're POSTing to /form to create it, the response should be 201 with a Location header that is the route where the created resource lives (not necessary to do either, but that's what the spec says should happen). It is, however, valid to POST to a route to create a resource that is not identified by a URI (which the existing test sorta does, even though you get the resource by GETting the same route).

So all of this is to say, while the existing test isn't wrong, it doesn't reveal much about the HTTP spec except that it's the wild west, and you can do basically whatever the hell you please. If you wanted to make this test more compliant with what the HTTP spec would really like you to do (but understand if you didn't), you should probably change the intermediate steps as well to assert the 201, the Location header, and that the subsequent PUT and DELETE operations work normally on the route for that resource.