[mdx] Joe on section 3.2.1

[Ian Young]

On 30 Sep 2013, at 20:34, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

> Actually if that's an encoded '+', it is a space. If it's not an encoded
> '+', then the URLs are already ugly, since a '+' has to be encoded (being
> that it encodes a space).

My brain hurts when I have to think about this part of spec land.

My understanding, refreshed by a bit of googling around including this...

http://stackoverflow.com/questions/5366007/why-does-the-encodings-of-a-url-and-the-query-string-part-differ/5433216#5433216

or

http://bit.ly/16aOpCs

… is that the ' ' becomes '+' rule only applies in the query part of a URL, or in form data, with a URL lacking a query part (which is what we have here) encoding ' ' as '%20'.

There's probably a lot of code that just assumes any '+' it sees anywhere really just means a space, though. I'm not sure we need to, as long as we are clear about what we are saying (I don't think we are at present).

> This is frankly why I don't like REST APIs, they try and avoid query
> strings when it's standard practice on the web to use them. The most
> appropriate syntax would be to define a parameter name to use and just
> have it appear more than once, and then your separator is just '&'.
> 
> Using PATH_INFO, we have to be clear about what we're presenting being
> encoded or unencoded.

I think a REST approach makes a lot of sense for single entity query:

   <base_url>/entities/<the_thing>

Using the URL hierarchy is also natural if you're digging down into sub-objects or whatever.

I don't think there is any natural way of putting more complicated grammars into REST form. Chad has tried to do it but clearly there are compromises already, and anything more complicated is not going to work at all.

I don't think this part of the spec has any implementation experience behind it, so in principle we could do something different. I don't think making everything a query parameter would look better for the simple case, but it would definitely look like a query!

I think it would also pretty much rule out any more general query language because there would be nowhere to put other operators than "and".  Not clear that would be a problem, though.

Can you give us a concrete proposal?

	-- Ian



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://lists.iay.org.uk/pipermail/mdx-iay.org.uk/attachments/20130930/01069ba5/attachment.bin>