我有一个投资组合，我在其中展示我的工作(主要是后端API的东西，与最少的UI交互(，目前正在记录API。我所拥有的是每个项目的一页以及属于它的文档；基本"；以其使用的资源(/todos、/posts…(命名的端点。GET /todos将从DB返回每个todos的列表，这是非常标准的东西。我也用一个"；基本"；/me端点能够返回当前登录用户的每种资源(可以是posts、todos…例如：GET /me/todos将返回当前用户的每一个todos(。
因为我每个项目/文档都有一个页面，所以我应该在一个单独的页面中列出并记录每个/me端点(例如，在我的"配置文件"页面中(，还是应该将它们放在各自的项目页面中？例如：在我的"；Todos"项目页面，我会记录每个/todos端点，也会记录每个项目的GET /me/todos等等。
我知道这听起来可能是一个愚蠢的问题，但把"；基本"；具有此GET /me/todos端点的项目的端点(例如：/todos((因为那时/todos端点似乎不再是"基础"端点(。但同时，我觉得有这个GET /me/todos记录在"；Todos"项目页面将有助于导航和阅读文档。
有人能给我指正确的方向吗？非常感谢
如果开发REST API，则存在统一接口约束，其中包括HATEOAS约束，该约束规定API必须提供超链接，客户端必须依赖超链接元数据而不是URI结构。类似于ReadMyTodos而不是GET /me/todos。最糟糕的解决方案是添加一个像{"ReadMyTodos": ["GET", "/me/todos"]}这样的映射来为客户端进行翻译，但你不会得到同样的体验，因为客户端不知道在哪个页面上允许什么，所以你也需要一个{"/me": ["ReadMyTodos", "ReadMyPosts"]}的映射。只有当每个用户在API中都有相同的角色，并且每个资源都支持相同的操作时，这才有效，支持的操作不依赖于资源状态，这是不可能的。通常，您的API不应该给出错误消息，因为您想要更新由管理员关闭的帖子。这是因为用于更新帖子的超链接根本不能显示在超链接列表中。如果你不返回超链接，那么客户端会在操作可用的情况下尝试，他们会毫无理由地依赖试错。
如果您不想使用上面的方法，因此我们讨论的不是REST API，那么GET /todos和GET /me/todos为同一用户返回不同的列表，那么您必须分别对它们进行文档记录。这并不一定意味着它们需要在单独的文档页面上。如果它们相互关联，则可以在单个页面上使用节/分区将它们分隔开。例如，你可以有与Todo相关的链接，并将它们记录在一个页面上，通常在页面顶部有一个链接列表，以及带有/docs/Todo#ReadMyTodos等部分标签的本地锚。