I am confused with respect to json:api's recommendations for URLs. The recommendation mentions that the type values and member names (of relationships and attributes) should ripple through to URLs:

It is recommended that the URL for a collection of resources be formed from the resource type.
...
It is recommended that a related resource URL be formed by appending the name of the relationship to the resource’s URL.

In turn, there are explicit recommendations for member names: use camelCase (#1297). For type values there are no explicit recommendations, but for consistency to me it makes sense to use the same convention here, because else you could end up having an API response that contains both kebab-case and camelCase. The idea of consistency between type vales and member names is supported by the spec:

The values of type members MUST adhere to the same constraints as member names.

So my reading is that if we choose to adhere to the extra camelCase constraint, it should also apply to type values.

So far all of this seems to suggest that urls should be camelCased too (i.e. /myModels/1/relationships/toOneRelationship). However, the async processing example does not seem to follow the outline above because queue-jobs is in kebab-case in both the type value and the URL.

What does this imply? Does it imply that type values can remain in kebab-case but member names should be pascalCase? This would mean we end up having kebab-case and pascalCase in both the api output and URL, which is not desirable? Or is it simply an example that choose to not follow the recommendations and in which kebab-case is used everywhere?

I'm trying to figure out what to do with my URLs. I understand these are just recommendations and I am free to do as I like, but I'm working on a json:api implementation (JsonApiDotNetCore) and I want to stay as close as possible to the specs and recommendations. Basically, the questions posed by @antonkomarev in #1255 at the bottem are pretty much the open questions I have too