在设计restful API时，在设计URI时需要考虑资源所有权。就我而言，我正在开发一个API，我的两个实体将是人和地址。每个人都可以拥有多个地址，因此在数据库中他们将位于不同的表中。
通常我只使用自动递增键，因此每次添加新记录都会增加ID号。
我的想法是，如果我使用这种方法，它会有效地产生这样的URI：
/people/11/addresses/52
在这种情况下，person 11 没有 52 addresses。它只是 11 的人，其地址的ID为 52 。
另一方面是我是否会使用这样的URI。地址通常不会被客户端自己检索，但作为单个API调用检索的人物对象的一部分（/people/11将检索与该人相关联的所有地址）。
无论如何，我想这里的问题是关于最佳实践。看到另一个拥有ID值的实体是否常见？这有什么一般做法？
答案 0 :(得分：3)
当您以个性化方式为人员实体返回地址的详细信息时，通常会使用以下资源：/ people / 11 / addresses / 52。
例如，如果您有实体：可以拥有地址的人员和办公室，以及您想要仅显示国家/地区的人员以及要显示地址的所有详细信息的人员。
另一方面，如果您不需要自定义，您还可以使用类似：/ address / 12的URL，因为这样可以更容易地缓存响应。
地址通常不会被客户自行检索， 但作为单个API调用检索的person对象的一部分 （/ people / 11将检索与该人相关的所有地址）。
如果是这种情况，您可以省略详细地址网址。
答案 1 :(得分：3)
你的方法是正确的。 这些也是一般规则（reference）：
- An API is a user interface for a developer - so put some effort into making it pleasant
- Use RESTful URLs and actions
- Use SSL everywhere, no exceptions
- An API is only as good as its documentation - so have great documentation
- Version via the URL, not via headers
- Use query parameters for advanced filtering, sorting & searching
- Provide a way to limit which fields are returned from the API
- Return something useful from POST, PATCH & PUT requests
- HATEOAS isn't practical just yet
- Use JSON where possible, XML only if you have to
- You should use camelCase with JSON, but snake_case is 20% easier to read
- Pretty print by default & ensure gzip is supported
- Don't use response envelopes by default
- Consider using JSON for POST, PUT and PATCH request bodies
- Paginate using Link headers
- Provide a way to autoload related resource representations
- Provide a way to override the HTTP method
- Provide useful response headers for rate limiting
- Use token based authentication, transported over OAuth2 where delegation is needed
- Include response headers that facilitate caching
- Define a consumable error payload
- Effectively use HTTP Status codes
网上还有很多参考文献。 This页面是一个好的开始。 这些也很有用：slide1，devzone tutorial
答案 2 :(得分：0)
是的，这是在API中应用多对多关系的正确方法。记得在返回值时检查id2是否属于id1。
要检索所有地址，正确的呼叫为/people/11/addresses。然后你知道你必须调用连接查询。