Naming endpoints and types for longer words

As i understand ut json:api has nouns in plural for naming endpoint and type.
For example endpoint “articles” have type “articles”.

What is a good naming convention on endpoints and type for for words (nouns) that consist of two words for example SchoolUnit?

endpoint name: /v2/school-units/{school-unit-code}
response:

{
“data”: {
“type”: “schoolunit”,
“id”: “1”,
“attributes”: {
// … this article’s attributes
},
“relationships”: {
// … this article’s relationships
}
}
}

Thank you!

JSON:API specification recommends camelCase: schoolUnits

Please find details about naming recommendation here: JSON:API — Recommendations

Hi!

Thank you for your answer.
So the solution for our endpointname is: /v2/schoolUnits/{school-unit-code} ?
Are you sure the rule applies on URLs for Resource Collections? I know camelCase is standard for attributes but I have never seen an endpoint with camelcase. Not in any blog (best practise), forum or source (like Fielding).
Some examples I could find: Use Plural Nouns for Collections Dont: Avoid CamelCase or Underscores.
Use hyphens (-) to improve the readability of URIs.
To make your URIs easy for people to scan and interpret, use the hyphen (-) character to improve the readability of names in long-path segments
http://api.example.com/devicemanagement/manageddevices/
http://api.example.com/device-management/managed-devices /This is much better version/

What value should I use in attribute type in the response if I use above example.

Im still not convinced if the json:api standard recommends camelCase.
I want to apply the json api standard but I cant find any good source with examples with plural nouns for a resource/type with wordword.

Do you have any other source that recommends using camelCase in endpoints (and type)?

TIA!
Best regards

JSON:API recommends camelCase also for URLs implicitly. The relevant statements are:

It is recommended that the URL for a collection of resources be formed from the resource type.

It is recommended that a relationship URL be formed by appending /relationships/ and the name of the relationship to the resource’s URL.

In both cases it does not mention to transform the resource type or name of the relationship from camelCase to kebab-case or snake_case.

Microsoft Graph REST API is one example among many which use camelCase in URLs for REST APIs.

I know microsoft lika camelCase but all other seems to use hyphens :grinning:.
For example Zalando
Example paths:

/shopping-carts/{country}/{session-id}
/shopping-carts/{country}/{session-id}/items/{item-id}
/api-specifications/{docker-image-id}/apis/{path}/{file-name}
/api-specifications/{repository-name}/{artifact-name}:{tag}
/article-size-advices/{sku}/{sales-channel}

https://opensource.zalando.com/restful-api-guidelines/

The standard best practice for REST APIs is to have a hyphen, not camelcase or underscores. This comes from Mark Masse’s “REST API Design Rulebook” from Oreilly.

It is recommended to use the spinal-case (which is highlighted by RFC3986), this case is used by Google, PayPal, and other big companies.

Microsoft says: DO use kebab-casing (preferred) or camel-casing for URL path segments. If the segment refers to a JSON field, use camel casing.
api-guidelines/azure/Guidelines.md at vNext · microsoft/api-guidelines · GitHub

Seems to me that Microsoft recommends kebab-casing in this case (my case) since Im referring to a value in a field/attribute (type) and not to a JSON field??

Hyphens and camelcase as value in the type field (attribute) feels weird but I guess it has to be same as the URI to be consistent :thinking: Or use best of both worlds (combination).

If I understand it correct most (almost all) would recommend this solution:

endpoint name: /v2/school-units/{school-unit-code}
response:

{
“data”: {
“type”: “school-units”,
“id”: “1”,
“attributes”: {
// … this schoolunit’s attributes
},
“relationships”: {
// … this schoolunit’s relationships
}
}
}

json:api recommends:

endpoint name: /v2/schoolUnit/{school-unit-code}
response:

{
“data”: {
“type”: “schoolUnit”,
“id”: “1”,
“attributes”: {
// … this schoolunit’s attributes
},
“relationships”: {
// … this schoolunit’s relationships
}
}
}

best of both worlds:

endpoint name: /articles/1 HTTP/1.1
{
“data”: {
“type”: “article”,
“id”: “1”,
“attributes”: {
// … this article’s attributes
},
“relationships”: {
// … this article’s relationships
}
}
}

endpoint name: /v2/school-units/{school-unit-code}
response:

{
“data”: {
“type”: “schoolUnit”,
“id”: “1”,
“attributes”: {
// … this schoolunit’s attributes
},
“relationships”: {
// … this schoolunit’s relationships
}
}
}

I will have to think about whether we should follow json:api and use camelCase in the uri and value in attribute type or make an exception in this case since most standards recommends hyphens (URL is case sensitive, its good for SEO to use hyphens and so on).

Maybe this is more correct?
json:api recommends:

endpoint name: /v2/schoolUnits/{school-unit-code}
response:

{
“data”: {
“type”: “schoolUnits”,
“id”: “1”,
“attributes”: {
// … this schoolunit’s attributes
},
“relationships”: {
// … this schoolunit’s relationships
}
}
}

other examples of type: address becomes addresses, email to emails, phoneNumber to phoneNumbers, enrolment to enrolments and person to persons (or people?).