基于替代标识符获取rest API中的资源

Posted 2021-04-03

什么是基于不同标识符获取资源的其他API约定？

例如

GET
/resource/{id}

GET
/resource/{guid}

由于这可以被视为一个重复的资源，并且为此设置路径可能是一个问题，那么什么是替代方案，那么将遵循其他API准则？

也许

/资源/？GUID = {GUID}

要么

/资源/ GUID / {GUID}

或者是其他东西？

答案

我通常不会复制端点。问题是：

为什么一个客户有id而另一个有guid？

什么设计选择允许这种情况发生？

我会将其作为单个资源端点保留：

GET
/resource/{id}

因此，通过其ID访问资源的客户端将使用上述端点。我允许通过他们的guid访问资源的客户交换他们所拥有的东西（guid）以满足他们的需要（id）：

GET
/id/{guid}

以上内容返回给定资源guid的资源ID。然后，客户端可以使用刚收到的id调用主资源端点：

GET
/resource/{id}

但最终我会研究为什么有些客户使用guid而不是id并更改它，以便所有客户端以相同的方式访问API。

另一答案

简短的回答

你可以使用/resource/{id}和/resource/{guid}。许多框架支持用于匹配路径参数值的正则表达式。

答案很长

REST是一种架构风格，而不是设计URI的手册（参见下面的注释）。它不强制执行任何URI设计，完全取决于您选择更好地识别您的资源的URI。

你应该记住的是：将multiple mappings用于同一个实体是完全没问题的。根据菲尔丁的论文，每个映射都是一种资源：

资源是到一组实体的概念映射，而不是与任何特定时间点的映射相对应的实体。

话虽如此，如果你支持DELETE，重要的是要提到它应该如何工作：

4.3.5. DELETE

DELETE方法请求源服务器删除目标资源与其当前功能之间的关联。实际上，此方法类似于UNIX中的rm命令：它表示对源服务器的URI映射执行删除操作，而不是期望删除先前关联的信息。 [...]

---

注1：URI语法在RFC 3986中定义。作为一般规则，路径以分层形式组织（由/分隔的段）并且可以在查询组件中包含非分层数据（从?开始）。

注2：REST架构风格在Roy T. Fielding的论文的chapter 5中描述，它定义了一组约束，这些约束必须遵循这种架构所遵循的应用程序。但它没有说明URI必须是什么样的。

注3：由Martin Fowler编写的popular article的例子解释了由Leonard Richardson定义的模型，这表明URI结构看起来很友好且易于阅读。