1

我有几个关于这里讨论的 SCIM api 端点的问题：http ://www.simplecloud.info/specs/draft-scim-api-01.html我认为这可能是一个很好的起点。

在规格中，我看到以下内容：

“SCIM 协议指定了用于管理核心模式中定义的资源的众所周知的端点和 HTTP 方法；即，用户和组资源分别对应于 /Users 和 /Groups。支持扩展资源的服务提供者应该使用已建立的约定定义资源端点；通过附加一个's'来复数扩展模式中定义的资源名称。鉴于存在资源复数化不明确的情况；例如，名为'person'的资源合法地是'persons'和'people'消费者应该通过架构子属性‘端点’。”

我不明白的是：

1) 我以前从未见过资源名称的大写。这对 SCIM 来说是新事物吗？默认情况下，浏览器中的 URL（与此相关的任何地方的 URL）不区分大小写，我们是否将其大写都没有关系。我真正的问题是将资源名称大写是规范的一部分还是只是一个示例？2）（这可能更像是 REST 规范和 SCIM 之间的一个网格问题）。我们有一个用户有“收藏夹”的场景。我们有两种方法可以处理这个问题：

/scim/v1/users/{userId}/favorites（我们可以称之为扩展子资源）

或者

/scim/favorites/users/{userId} （我们可以将所有这些扩展资源“收藏”）。

从 url 的角度来看，两者似乎都是正确的，但我不知道哪一个更适合根据 SCIM（也许是 REST？）规范。一个后续问题可能是，扩展资源是否也必须资本化？

感谢所有帮助！我是实施和理解 SCIM 的新手，所以如果我遗漏了规范本身中的一些微妙指示，请原谅我！

干杯并期待任何可以帮助我理解这一点的答案！

4

1 回答 1

3

URL 一直是区分大小写的。然而，主机名不是。

http://example.com/User?id=JohnDoe并且http://ExAmPlE.cOM/User?id=JohnDoe应该解析到相同的资源，即使 URL 不相同。但 URL 区分大小写。

由于规范是指定Users而不是users，因此大小写很重要。

这很重要，因为规范是这样说的。此外，如果不出意外，其他阅读规范的人将使用Usersvs users。

关于 REST，这些 URL 无关紧要，因为 REST 不关心 URL。

但这不是 REST。这是一个基于 HTTP 的规范。它与 REST 无关。

附加物：

他们可以随心所欲地称其为 REST API，但事实并非如此。他们还称其为“REST 协议”，这没有任何意义，因为 REST 是一种架构。HTTP 是一种协议。您可以在 HTTP 之上构建一个 REST 架构的应用程序，但您不必这样做。REST 与 HTTP 无关。

REST 不关心 URL 的原因与您不关心的原因相同。REST 中的一个关键原则是 HATEOAS，它本质上是识别资源中的链接并遵循它们。你知道亚马逊的“结帐”链接是什么吗？不？然而你仍然设法在那里购物？这是可能的，因为您点击了“结帐”链接，而不是因为您知道 URL 是什么。

REST 架构中正确设计的客户端只需遵循有效负载中提供给它的 URL。URL 对它是不透明的。客户端只需要被告知服务的入口点（如果你愿意的话是主页），它可以通过它在有效负载中找到的众所周知的链接标识符（rels）自行从那里导航。

这个规范几乎没有。

考虑在规范中他们如何说版本控制是可选的。因此，这意味着 URL 可以是 /v1/Users 或只是 /Users。您在客户端中编码哪个 URL？你怎么知道有人在运行什么版本？如果您使用的服务之前没有版本化并变成了版本怎么办？您所有的 URL 都会中断。如果你想让一个协议在野外实现起来很愉快，可以在基础知识中添加可选元素，比如如何访问它。

考虑他们谈论从组中删除用户的 PATCH 部分。他们有：

  "display": "Babs Jensen",
  "value": "2819c223-7f76-453a-919d-413861904646"
  "operation": "delete"

是什么value？看起来像某种“用户ID”。然而，URL 应该是用户 ID。无论是http://example.com/Users/1234还是http://example.com/shippingdepartment/v1/Users/1234还是http://example.com/beta/notforpublication/Users/1234。这是一个唯一的标识符。简单地1234告诉你什么？不够。

使用 HATEOAS，您的客户不必“知道”如何“构建”这些 URL 并弄错。服务器告诉客户端这些是什么。

当您想要 GET：http ://www.example.com/Users/1234并且他们切换到 /v2 时会发生什么？在 HTTP 上的 REST 中，服务器可以使用301 Moved PermanentlyLocation: http://www.beta.example.com/v2/users/4567/core进行响应。服务器刚刚告诉您的客户端此资源已移动。不仅是“ID”（1234 到 4567），还有路径（/Users/1234 到 /v2/users/4567/core），甚至是主机（www.example.come 到 www.beta.example.com） . 您的客户怎么会知道如何构建新的 URL？

所以，1234 是不够的。不透明的 URL 更加健壮。就像你在编程中不关心指针的值是什么一样，你只关心它所指向的东西，以及为什么指针数学会导致更多麻烦。

如果他们在这些组中使用 URL，那么您可以拥有跨域用户组！多么新颖的想法。您可以在同一组中拥有 v1 和 v2 用户。各种各样的事情。

至于#2，子资源和其他什么，这是一个品味问题——你的品味，正如你所看到的，从高级 REST 的角度来看，客户并不关心你做什么。

于 2013-12-11T00:44:25.163 回答