WSF_POST_HELPER does not support non-RESTful POSTs

[colin-adams]

The use of POST on an existing resource (such as when POST is used as a GET), although not RESTful, is allowed by HTTP/1.1 ("The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result.")

Send_response in this class is not fully supportive anyway (see comment), but it ought to check if a_new_resource is False, and call a different routine (other than append_resource, which is not appropriate in these circumstances).

[colin-adams]

Also will need to add the simple CORS support added for GET by issue #149.

[colin-adams]

The description of this issue is largely wrong.

POST is NORMALLY used on an existing resource.

We have 3 cases:

1. POST used on a non-existing resource. Send_response is called with a_new_resource set to True. But this flag is ignored. To have a strict RESTful interpretation, this should result in a new subordinate resource, and the requested (parent) resource should still not be GETable (but the newly POSTed resource may well be). Probably this use case works OK.
2. POST used on an existing resource in a strictly RESTful sense (creation of a sub-ordinate resource). Probably this use case works OK too.

In both these cases, the framework could provide more support though. Especially for generating responses.

3. POST used as a GET (with a message entity providing parameters). Not RESTful. Again, the framework is adequate for this case (assuming responses are cachable), just not very supportive.

Not sure what to do with this issue. Suspendeding it for now.