SCIM端点和SCIM中的其他扩展资源

Question

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

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

“SCIM协议为管理核心模式中定义的资源指定了众所周知的端点和HTTP方法；也就是说，用户资源和组资源分别对应于/Users和/Groups。支持扩展资源的服务提供者应该使用已建立的约定定义资源端点；通过附加一个's‘来使扩展模式中定义的资源名称多元化。在有些情况下，资源多元化是模糊的；例如，名为'person’的资源是合法的‘person’和'people‘使用者应该通过schema Sub-属性’终结点‘发现资源终结点。”

我不明白的是以下几点：

( 1)我从未见过资源名称的大写化。这对SCIM来说是新的东西吗？默认情况下，浏览器中的Urls (urls在任何地方)都是不区分大小写的，不管我们是否大写它。我真正的问题将是将资源名称大写为规范的一部分，或者仅仅是一个示例? 2) (这可能是REST规范和SCIM之间的一个比较复杂的问题)。我们有一个用户有“收藏”的场景。我们可以通过两种方法来处理这一问题：

/scim/v1/user/{userId}/favorites(我们可以称之为扩展子资源)

或

/scim/收藏夹/用户/{userId}(我们所有这些都可以扩展资源“收藏”)。

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

感谢所有的帮助！我是新的实现和理解SCIM，所以请原谅我，如果我错过了一些微妙的指点在规范本身！

干杯，期待任何能帮助我理解这一点的答案！

Answer 1

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

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

由于规范指定的是Users而不是users，所以大小写非常重要。

这很重要，因为规范是这么说的。另外，如果没有其他的话，其他阅读规范的人将使用Users和users。

关于REST，这些URL并不重要，因为REST并不关心URL。

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

增编：

他们可以随心所欲地把它称为REST，但并不是这样。他们还称它为"REST协议“，这是毫无意义的，因为REST是一种体系结构。HTTP是一种协议。您可以在HTTP之上构建一个REST架构的应用程序，但不必这样做。REST与HTTP无关。

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

REST体系结构中设计正确的客户端只需遵循负载中提供给它的URL。URL对它是不透明的。只需要告诉客户端服务的入口点(如果您愿意的话是主页)，它就可以通过它在有效载荷中找到的熟悉的链接标识符(rels)从那里导航。

这个规范几乎没有这方面的内容。

在规范中考虑一下他们是如何说版本控制是可选的。因此，这意味着URL可以是/v1/用户，也可以是/Users。您在客户端中编码的是哪个URL？你怎么知道有人在运行哪个版本？如果您正在使用的服务以前没有版本化，并且变成了版本化，那么该怎么办？你所有的网址都坏了。如果您想让协议轻松地在野外实现，可以在基础元素中添加可选元素，比如如何访问它。

考虑他们谈论从组中删除用户的修补程序部分。他们有：

  "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，并且会出错。服务器告诉客户机它们是什么。

当你想要得到时会发生什么：http://www.example.com/Users/1234和他们改变为/v2？在HTTP上的REST中，服务器可以使用一个位置：301 Moved Permanently ( http://www.beta.example.com/v2/users/4567/core )来响应。服务器刚刚告诉客户端，这个资源已经移动了。不仅仅是"ID“(1234到4567)，还有路径(/user/1234到/v2/user/4567/core)，甚至主机(www.example.come到www.beta.example.com)。你的客户怎么知道如何构建新的URL呢？

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

如果他们在这些组中使用URL，那么您可以拥有跨域用户组！真是个新奇的主意。您可以将v1和v2用户放在同一个组中。各种各样的事情。

至于#2，子资源和什么不是，这是品味的问题--你的品味，正如你所看到的，从高层次的休息角度来看，客户不关心你做什么。