api - RESTful API 设计 : ID values for "owned" resources

Question

在设计 restful API 时，资源所有权是设计 URI 时的一个考虑因素。就我而言，我正在开发一个 API，其中我的两个实体将是人和地址。每个人可以有多个地址，因此在数据库中，他们将在不同的表中。

通常我只是使用自增键，所以每增加一条新记录都会增加ID号。

我的想法是，如果我使用这种方法，它会有效地生成一个像这样的 URI:

/people/11/addresses/52

在这种情况下，人 11 没有52 地址。这只是个人 11，他的地址 ID 为 52。

另一方面是我是否会使用那样的 URI。地址通常不会由客户端自行检索，而是作为通过单个 API 调用检索的人员对象的一部分(/people/11 将检索与该人员关联的所有地址)。

无论如何，我想这里的问题是关于最佳实践的。看到另一个拥有的实体具有这样的 ID 值是否很常见？这方面的一般做法是什么？

Answer 1

你的方法是正确的。这些也是一般规则(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