Subject: GET/POST parameters question

From: Grahame Grieve <[email-masked]>
Date: Tue, 12 Jun 2018 06:44:02 +1000

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.

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.

Has this been discussed? does this group have an opinion?

thanks
Grahame

-- 
-----
http://www.healthintersections.com.au / [email-masked]
/ +61 411 867 065

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 11 Jun 2018 14:05:00 -0700

> On Jun 11, 2018, at 1:44 PM, Grahame Grieve <[email-masked]> 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

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 11 Jun 2018 23:20:57 +0200

On Mon, Jun 11, 2018 at 02:05:00PM -0700, Roy T. Fielding wrote:
> Presumably, an application will use parameters when

Several years ago for an application I was working on, I explicitly
wanted to support both url-params and body for POST requests because
for me they are completely different and orthogonal beasts. But I
found that it doesn't cope well with a number of application frameworks
which are confused because (probably due to inheritance of the old days
of CGI), for them a parameter is a parameter, wherever it's found, so
these were completely mixed at various places in the chain. Thus I
gave up, a bit sadly, considering that I was prevented from doing it
just due to the risk of poor interoperability at some places and not
for any technical reason.

Cheers,
Willy

---

From: Grahame Grieve <[email-masked]>
Date: Tue, 12 Jun 2018 08:49:20 +1000

thank you both

Grahame

---

From: Philipp Junghannß <[email-masked]>
Date: Tue, 12 Jun 2018 01:10:00 +0200

>From my experience combining them can be pretty useful and I dont really
see any reason it shouldnt be allowed, but one important thing is that you
make sure that the server properly seperates any parameters you get by
their origin (post, get, cookies, anything else) or otherwise you may land
in some serious chaos (while on an API I doubt you would have users end in
that by any malicious means, if one on accident chooses a name for a
varable for POST that already exists in GET and you need both at the same
time and they arent seperated it wont be fun.

In other words do not use $_REQUEST of PHP or any equivalent in any given
language, but instead target post, get etc parameters specifically and you
are fine.

Regards.

---

From: Grahame Grieve <[email-masked]>
Date: Tue, 12 Jun 2018 09:11:59 +1000

why is it useful?

grahame

On Tue, Jun 12, 2018 at 9:10 AM, Philipp Junghannß <[email-masked]
> wrote:

>> http://www.healthintersections.com.au / grahame@healthintersections.
>> com.au / +61 411 867 065
>>
>

---

From: Philipp Junghannß <[email-masked]>
Date: Tue, 12 Jun 2018 11:35:21 +0200

and that is not just for pre-rest.

HTTP isnt just for Rest APIs but also for websites and when you have one
endpoint capable of doing multiple things you obviously throw what generic
thing to do into the GET because you want it as a link.

when you now want to POST something on that page the advantage if that your
script doesnt need to put the get parameters into the form as hidden inputs
or whatever but they just come along as get parameters because they have
already been there, which simplifies it a bit.

Am Di., 12. Juni 2018 um 01:30 Uhr schrieb Jim Manico <[email-masked]>:

> Pre REST I might want to add non-sensitive data to my action to determine
> WHAT action I want from a service endpoint. Like...
>
> https://posting.something.com/to?action=updateUser
>
> ... then I want my sensitive data in the POST payload/body. This is old
> school but not uncommon.
>
> But in my world I would never clobber URL and payload variable names so
> these issues never showed up.
>
> Aloha, Jim
>
> On Jun 11, 2018, at 6:11 PM, Grahame Grieve <
> [email-masked]> wrote:
>
> why is it useful?
>
> grahame
>
>
> On Tue, Jun 12, 2018 at 9:10 AM, Philipp Junghannß <
> [email-masked]> wrote:
>
>>> http://www.healthintersections.com.au /
>>> [email-masked] / +61 411 867 065
>>>
>>
>
>
> --
> -----