isnt it content because that it the name of the component - which is consistent with all other routes in both the web ui and webservices

Additionally articles is only the english word used when referring to content items

isnt it content because that it the name of the component - which is consistent with all other routes in both the web ui and webservices

I can imagine that's the reason. But must that also be the reason for naming the endpoints? To be honest, I always had mixed feelings with the name com_content to start with. A bit too generic for a very specific content type in a Content Management System :)

Additionally articles is only the english word used when referring to content items

Not sure what you mean. Can you explain?

@alikon I think you have to change API tests, too: https://ci.joomla.org/joomla/joomla-cms/45112/1/25

Additionally articles is only the english word used when referring to content items

Not sure what you mean. Can you explain?
com_content => /v1/content
com_banners => /v1/banners

There is logic in that naming that anyone can understand by looking at the filesystem etc

com_content refers to articles in english and but articoli in Italian and Artikel in Dutch etc

@richard67
sure i'll do when and if there will be some consensus
it's a RFC draft pr

To me, content is redundant and could be removed. We have v1/contacts, v1/banners, so having v1/articles make more sense and it is consistent with other component.

Looking at fields related routers, I wonder if we should change it, too. In theory, in relation with articles, fields are not much different with categories. We have v1/articles/categories, so v1/articles/fields is logical (to me), too.

How about change fields routers as follow:

v1/fields/articles => v1/articles/fields
v1/fields/groups/articles =>v1/articles/fields/groups
v1/fields/articles/categories=> v1/articles/categories/fields
v1/fields/groups/articles/categories => v1/articles/categories/fields/groups

Also dont want to put a spanner in the works but this would be a change in the API which would be forbidden by the current RC status

com_content => /v1/content
com_banners => /v1/banners

There is logic in that naming that anyone can understand by looking at the filesystem etc

I'm not convinced that filesystem based association is the best motivation to base the naming of api endpoints on. For me, if I want to retrieve articles, the content part of the current endpoints is just overkill and does not add anything.

The logic you are referring to may benefit code base maintainers. However, my guess is they know perfectly well what's meant by articles, without explicitly referring to the component that implements them. I don't think the naming logic benefits api consumers though. If anything, it may confuse them, by a lack of consistency.

I thing consistency is key. We have had to deal with enough inconsistencies in Joomla! in the past as it is. I would love to see that change. A new major version and a completely new web services subsystem is a perfect opportunity to set that in motion :)

By the way, funny that you mention banners. Why don't those endpoints have the component name in them? Just because /v1/banners/banners looks a bit weird?

Also dont want to put a spanner in the works but this would be a change in the API which would be forbidden by the current RC status

Sadly, we might have to do the change with webservices. For example, the change in this PR #34488 , in theory, it changes Public API, but we really should make that change instead of having to keep it for years ahead :(.

fixing a bug is different