如果资源 ID 已知，为什么还要通过 REST API URI 传递它们？
Why passing resources ids via REST API URI if they already known?
我研究了 URI 设计最佳实践的各种资源。几乎每个作者或博主都说 RESTFul API URI 必须像这样。
/* List all users in account 2 where user id is 1 */
`/users/1/accounts/2/users` [GET]
Above api 调用者必须在每个请求中传递以上两个 id。
但我的情况完全不同。
在我的 API 服务器之前有一个资源管理器 (RM)，所以每个请求都必须通过 RM 进行身份验证，并使用有效 token 才能访问上面的示例 API。 注意：[令牌通过 header]
发送
在 return RM 中授权请求后，通过拦截器向我的 API 服务器提供用户信息，即（user_id、account_id 等）。
问题是我的 API 服务器已经知道 user_id 和他的 account_id 那么仍然需要在 API URI 中获取这些信息。
我试过以下设计：
1. /users/accounts/users
2. /accounts/users
3. /users
最适合这种情况的设计是什么？我花了两个星期但无法决定，因为这些是企业 API 的设计；一次设计，永不改变。
出于您最后给出的原因，您应该在 URI 中包含 ID - 您的 API 将 非常 很难，也许不可能，一旦它被改变正在使用。另一方面，您的实施 将 随着时间的推移而改变。您的身份验证/授权机制可能会改变。您的企业可能希望转向 不 以这种方式传递 id 的模型，他们当然不希望发现他们必须重新设计每个 API 这取决于旧行为。
归根结底，在 URI 中包含足够的信息以供 URI 识别与其相关的资源是 ReST 的关键部分。 URI 应该是 all，您需要识别资源，您不依赖带外信息或实现细节来进一步识别您正在寻址的资源。
我研究了 URI 设计最佳实践的各种资源。几乎每个作者或博主都说 RESTFul API URI 必须像这样。
/* List all users in account 2 where user id is 1 */
`/users/1/accounts/2/users` [GET]
Above api 调用者必须在每个请求中传递以上两个 id。
但我的情况完全不同。
在我的 API 服务器之前有一个资源管理器 (RM)，所以每个请求都必须通过 RM 进行身份验证，并使用有效 token 才能访问上面的示例 API。 注意：[令牌通过 header]
在 return RM 中授权请求后，通过拦截器向我的 API 服务器提供用户信息，即（user_id、account_id 等）。
问题是我的 API 服务器已经知道 user_id 和他的 account_id 那么仍然需要在 API URI 中获取这些信息。
我试过以下设计：
1. /users/accounts/users
2. /accounts/users
3. /users
最适合这种情况的设计是什么？我花了两个星期但无法决定，因为这些是企业 API 的设计；一次设计，永不改变。
出于您最后给出的原因，您应该在 URI 中包含 ID - 您的 API 将 非常 很难，也许不可能，一旦它被改变正在使用。另一方面，您的实施 将 随着时间的推移而改变。您的身份验证/授权机制可能会改变。您的企业可能希望转向 不 以这种方式传递 id 的模型，他们当然不希望发现他们必须重新设计每个 API 这取决于旧行为。
归根结底，在 URI 中包含足够的信息以供 URI 识别与其相关的资源是 ReST 的关键部分。 URI 应该是 all，您需要识别资源，您不依赖带外信息或实现细节来进一步识别您正在寻址的资源。