Details
-
Improvement
-
Resolution: Done
-
Neutral
-
None
-
None
-
None
Description
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
- ...
Checklists
Attachments
Issue Links
- relates to
-
MGNLREST-319 DOC: Content Management API
-
- Closed
-