(not a CFML question, sorry, but it's CFML-adjacent at least): Ignoring personal preference and any strong opinions not backed by anything authoritative... does anyone know of any industry guidelines as to a position to take on the casing URL query parameters, eg:

<http://example.com/path/to/something?SomeParam=x>

vs

<http://example.com/path/to/something?someparam=x>

, vs

<http://example.com/path/to/something?some_param=x>

, vs

<http://example.com/path/to/something?some-param=x>

. I know the accepted recommendation for the path part is kebab case. I'm specifically looking at the query string parameter names. I can't stress enough I don't give a shit what your personal opinion is (I already have that covered). I'm looking for guidelines. I'm drawing a blank on google.

From an SEO standpoint, I have often read that it is best to use hyphens to separate words. https://aicontentfy.com/en/blog/how-to-structure-urls-for-better-seo https://www.stanventures.com/blog/underscore-in-url/

Where does the "I know the accepted recommendation for the path part is kebab case." come from?

Yeah it's defining processing/interpretation guidelines. Situation is we have old system using

snake_case

(for poorly-thought-out reasons, but we're stuck with it) for its variables, and it's talking to our API (new, under development now), which uses

camelCase

. We've just added a new endpoint and integrating it back into the old system, and we've used

?my_param=value

, whereas my take would be "no that's legacy, we're not perpetuating that... use

?myParam=value

. But then I started thinking even MORE about it, and wondering if there's firm guidelines. I suspect there is not.

Personal preference was always to use camel case, mostly for readability. Many web servers/proxies also upper-case them when they pass them to the app server... so it really matters less on the key. Value was passed in as it was entered.

Where does the "I know the accepted recommendation for the path part is kebab case." come from?

Ppl used to have to type urls and can't remember casing, plus

_

tends to get subsumed in a hyperlink underline or confused for a space, so

-

became the recommendation.

Yeah, but where's that recommendation?

oh... buh... from the back of my mind as I've seen it so many times. I'm not looking @ anything in particular when I say that. I mostly mentioned it cos I wanted to deflect from ppl answering that part of the question (which was not part of the question), and stick to "query param names"

From a corporate standpoint, "does it function? yes..." "okay move on, no need to waste time/$$" 😂

I'm asking that as a legitimate question. We're in a similar situation of re-working some legacy stuff into a new system and if I'm going to recommend an approach, my teammates will skewer me (on a lowercase kebab?) if the best basis i can come up with is "Adam said it on Slack" in pressing for it. (sorry to side-track this from the emphasis on parameter naming) and I've seen instances of the same thing that @quetwo noted: the intervening proxy/WAF layers can dork with casing on the parameter names anyway, so that aspect doesn't matter to us. to work around that, we deal with parameter names in a case-insenstive way.

Doesn't "Adam said it on Slack" automatically become industry standard? If not I may be in trouble.

that, and "i read it on Adam's blog..."

From a corporate standpoint,

100%. I am the corporate part in this case (not the dev), but this is the first instance of this Q coming up in an API that is going to grow a lot, so I want to have the discussion now, and then move on. And, fwiw, I have said "it's not enough to hold up the code going out the door if no clear answer surfaces quickly"

Then I would follow some standards of 2-3 large scale corporations in the tech sector with APIs....look at FB or Google etc

I think it's suffice to say "There is no written standard." And as an architect of a system, you get to decide.

Ooh @Patrick I like that suggestion. However my will to live for the day has been eroded, so I will come back to that tomorrow. For now... I think I need a 🍺

I've avoided hyphens as often as possible just due to an occasional oddity here and there where I passed in "page-1" and whatever language I was in (I wanna say it was PHP) interpreted it as page minus one and blew up spectacularly. That was well over a decade ago and I haven't seen it too often but it scarred me I guess lol. It might even have been something awful and not-recommended I was doing in JS actually. Anyway, yeah, hi Adam lol.

Sounds like you were doing an eval() or something on the var name

Yeah that sort of thing is def possible. Lucee does this stupid thing with

first.second=value

where it converts that to a struct. FFS. Not sure PHP would do what you said, but if it was back in its old days... wouldn't surprise me.

Yeah this was looooooong ago. 15 years? Maybe more. I should probably talk to my therapist about it, clearly I'm harboring some hyphen trauma 😄

you mean hyphen-trauma

I avoid hyphens and underscores; partially do to how some foreign browsers and UTF's can transform and read this differently

I haven't been able to rustle up any specific guidelines, but the SEO folks have opinions about this (which only applies to public URLs). Overall, there seems to be a consensus for URLs to all lowercase including query params so that you don't have the potential for confusion between

I

and

l

for example (capital

i

and lowercase

l

). At a minimum, make sure they are not case-sensitive was also seemingly the consensus.

For what worth one might place on this and recognizing that it is provided in the context of facilitating G crawling, https://developers.google.com/search/docs/crawling-indexing/url-structure recommends use of hyphens and recommends against using underscores, and their example shows those recommendations on both the path portion and parameters. For situations where case doesn't matter to the server (i.e., where they are treated the same), they recommend everything being the same case for consistency. This (https://designpowers.com/blog/url-best-practices) recommends hyphens and lowercase. This (https://www.collaborada.com/blog/url-best-practices) also recommends hyphens and lowercase (specifically, recommends avoiding uppercase letters). There does seem to be some consensus around those aspects.

Interesting. This is for an API, so SEO is not an issue. And we had the conversation about

/subthing/thing=1

(filter) vs

/thing/1/subthing/

(subcollection) and went "doh... yeah next time", but I'm OK positioning it as a filter for now. Although it should be the latter.