REST API中的信息性与唯一生成的ID

Question

设计RESTful API.我有两种识别资源的方法(人员数据).通过数据库生成的唯一ID或通过社会安全号码(SSN)为每个人输入.SSN应该是唯一的,但可以改变.

使用ID对我来说最方便,因为它保证是唯一的,并且不会改变.因此,资源的URL也始终保持不变:

GET /persons/12

{
  "name": Morgan
  "ssn": "840212-3312"
}

使用SSN的理由是API客户端提供更多信息和理解.SSN在周围系统中的使用更多:

GET /persons/840212-3321

{
  "name": Morgan
  "id": "12"
}

所以问题是:我应该采用第一种方法,并避免一些SSN可能发生变化的实施难题.也许提供一些从SSN转换为ID的辅助方法？

或者采用第二种方法.提供更丰富的API.虽然不得不处理一些不那么REST的陌生感,其中URL:s可能因SSN更改而改变？

Answer 1

网址设计是个人选择.但是为了给你一些与Ray已经提供的不同的例子,我会给你一些我自己的.

我有一个用户帐户资源,并允许通过两个URI访问:

/users/12

和

/users/morgan

其中数值是auto_incremented ID,字母值是用户指定的系统上的唯一用户名.这些资源是无法访问的,所以我不打扰规范化,但/users页面链接到字母表格.

我的系统上没有其他资源有两个独特的领域,因此是由id称,/jobs/123,/quotations/456.

正如您所看到的,我更喜欢多个URI段;-)
我认为"作业123"来自"作业"集合,因此拥有"作业"资源似乎合乎逻辑,每个作业都有子资源.

您不需要单独的/search/区域来执行搜索,我认为将搜索条件直接应用于集合资源会更加清晰:

/people?ssn=123456-7890  (people with SSN matching/containing "123456-7890")
/people?name=morgan      (people who's name is/contains "Morgan")

我有类似的东西,但只使用第一个字母作为过滤器:

/sites?alpha=f

列出以F开头的所有站点.您可以将其视为过滤器或搜索条件,这些术语只是同一个硬币的不同侧面.