Coming over from SUPPORT-13005, when talking about our Delivery API, I often end up referring to our docs, end there it says Delivery endpoint API v2, which first, reads awkward.

Second, the "endpoint" term is in fact quite ambiguous for many users. Some confuse it with API (actually we do*, in our code), some with "resources", etc.

* As I stated in my comment on SUPPORT-13005, I would argue that the Delivery API consists of 3 endpoints (or whatever we prefer to call them). So I would not refer to the grouping entity as endpoint anymore. Conversely, I'd consider an alternative name to the "rest-endpoints" directory in future iterations of light-development.

In a first step, it would be interesting to compare with a few CMS/REST docs how those different locators within APIs are called, and consider tuning our docs. What do you think about that? Any opinion? gut-feeling what it would take?

Additionally, we might consider simplifying the API tree of our docs as well, e.g.

• API
  • Delivery API (would ditch v1 docs by now)
  • SPA Template Definitions API (would list both /template-definitions and /template-annotations under the same API page here)
  • GraphQL API
  • Commands API
  • Nodes/Properties API (legacy)
• Java Server APIs
  • JCR API
  • DAM API
  • ...