Re: GET/POST parameters question

> On Jun 11, 2018, at 1:44 PM, Grahame Grieve <grahame@healthintersections.com.au> wrote:
> 
> hi
> 
> HTTP allows for parameters in the URL, and also you can submit parameters in the body as well with mime types application/x-www-form-urlencoded or multipart/form-data. Combining these in a single query has created confusion in the FHIR community (a RESTful spec for healthcare). We're being asking to say, in our specification, whether his is allowed, required, or prohibited. 

Parameters can be received in any or all of those places (including on every path segment).
They are all different.

How or why you would want to design a resource identifier in that way has nothing to do
with HTTP (and certainly nothing to do with REST). Whether or not you want to restrict
such a thing for FHIR is up to you, though I personally see no reason to exclude them.

> it seems to me that this is not something we should rule on in a derived spec; either HTTP allows it for a good reason, and we should allow it, or it's a bad idea and it shouldn't be allowed at the HTTP level. But we can't find much good information about this on the web.

HTTP has no reason to disallow it.  Presumably, an application will use parameters when
and where desired. If not desired, a 404 error is a normal response.

....Roy