RESTFul API设计建议

时间:2018-07-30 09:14:01

标签: rest api restful-architecture restful-url

我正在研究RESTFul API设计,并对以下用例感到困惑:

我有用户和用户借贷的地方。 API是必需的 a)用户管理 b)获取所选用户的贷款信息。

用例a)非常简单。端点将为GET / api / users /以获取用户信息。 如何设计API端点以获取用户的负载信息:

GET /api/loans/<user unique id>/
or
GET /api/users/<user unique id>/loans

请注意,这与用于唯一标识用户的方式不同。

任何建议将不胜感激。

谢谢你,
拉吉

1 个答案:

答案 0 :(得分:0)

REST不在乎您为资源标识符使用什么拼写。

因此,标识符的拼写与变量名的拼写非常相似。选择符合当地约定的拼写是一个好主意。

URI规范将hierarchical information与非分层信息区分开。可以合理地说“鲍勃的贷款集合”在等级上是从属于“鲍勃”的,标识符的拼写应该反映这一点

/api/users/12345
/api/users/12345/loans

此拼写的另一个优点是,由于relative references

,引用Bob的其他资源非常简单。
uri(/api/users/12345/addresses) === uri(/api/users/12345/loans).resolve(../addresses)

但是,这对资源之间的关系没有任何影响。例如,成功/api/users/12345的不安全请求将invalidate先前缓存的资源表示形式,但这对/api/users/12345/loans根本没有任何影响。

例如:

GET /api/users/12345/loans
DELETE /api/users/12345

就客户而言,标识符拼写上的相似之处并不意味着这两种资源之间有任何特殊关系。即使用户资源已删除,loans资源在缓存中的表示仍将视为有效。