W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2018

Re: GET/POST parameters question

From: Roy T. Fielding <fielding@gbiv.com>
Date: Mon, 11 Jun 2018 14:05:00 -0700
Message-Id: <A117A789-61A8-456B-9AFC-4D5D96658DAA@gbiv.com>
Cc: ietf-http-wg@w3.org
To: Grahame Grieve <grahame@healthintersections.com.au>
> 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


Received on Monday, 11 June 2018 21:05:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:21 UTC