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

时间:2013-12-11 00:09:52

标签: rest url oauth-2.0 url-scheme scim

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

在规格中我看到以下内容:

“SCIM协议指定用于管理核心模式中定义的资源的众所周知的端点和HTTP方法;即,用户和组资源分别对应于/ Users和/ Groups。支持扩展资源的服务提供者应该使用以下方法定义资源端点已建立的约定;通过附加's'来复用扩展模式中定义的资源名称。鉴于存在资源多元化不明确的情况;例如,名为“人”的资源合法地是“人”和“人”消费者应该发现资源端点通过Schema子属性'端点'。“

我不明白的是:

1)之前我从未见过资源名称的大写。这对SCIM来说是新事物吗?浏览器中的网址(任何地方的网址)默认情况下不区分大小写,如果我们将其大写,则无关紧要。我真正的问题是将资源名称大写为规范的一部分还是只是一个例子? 2)(这可能更像是REST规范和SCIM之间的网格问题)。我们有一个用户拥有“收藏夹”的场景。我们有两种方法可以解决这个问题:

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

OR

/ scim / favorites / users / {userId}(我们所有这些都是扩展资源“收藏夹”)。

从网址角度来看,两者似乎都是正确的,但根据SCIM(可能还有REST?)规范,我不知道哪一个更合适。还有一个可能的后续问题,扩展资源是否也必须大写?

感谢所有帮助!我是实施和理解SCIM的新手,所以如果我错过了规范本身的一些细微指示,请原谅我!

欢呼并期待任何可以帮助我理解这一点的答案!

1 个答案:

答案 0 :(得分:3)

网址始终区分大小写。但是,HOST名称不是。

即使网址不相同,

http://example.com/User?id=JohnDoehttp://ExAmPlE.cOM/User?id=JohnDoe也应解析为相同的资源。但该URL区分大小写。

由于规范指定Users而不是users,因此外壳很重要。

这很重要,因为规范说明了这一点。此外,如果没有别的,其他阅读规范的人将使用Users vs users

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

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

附录:

他们可以称之为REST API,但它并不是这样。他们也称之为“REST协议”,因为REST是一种架构,所以没有任何意义。 HTTP是一种协议。您可以在HTTP之上构建REST架构应用程序,但您不必这样做。 REST与HTTP无关。

REST并不关心URL,原因与您不同意。 REST中的一个关键原则是HATEOAS,它实质上是识别资源中的链接并跟随它们。你知道亚马逊的“结账”链接是什么吗?没有?然而你仍然设法在那里购物?这是可能的,因为您遵循“结帐”链接,而不是因为您知道URL是什么。

REST架构中设计合理的客户端只需遵循有效负载内给定的URL。这些网址对它不透明。客户端只需要告知服务的入口点(主页,如果你愿意),它可以通过它在有效载荷中找到的熟知的链接标识符(rels)自己导航。

这个规格几乎没有。

在规范中考虑他们如何说版本控制是可选的。所以,这意味着URL可以是/ v1 / Users或者只是/ Users。您在客户端编码哪个URL?你怎么知道有人在运行什么版本?如果您使用的服务之前未进行版本化并变为版本,该怎么办?您的所有网址都已中断。如果您希望在野外实现协议,请将OPTIONAL元素添加到基础知识中,例如如何访问它。

考虑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,并且弄错了。服务器告诉客户端它们是什么。

当您想要获取时会发生什么:http://www.example.com/Users/1234并且他们会切换到/ v2?在REST on HTTP上,服务器可以使用位置http://www.beta.example.com/v2/users/4567/core301 Moved Permanently进行响应。服务器刚告诉您的客户端此资源已移动。不只是“ID”(1234到4567),而是路径(/ Users / 1234到/ v2 / users / 4567 / core),甚至是HOST(www.example.come to www.beta.example.com) 。您的客户如何知道如何构建新网址?

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

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

对于#2,子资源以及什么不是,这是品味问题 - 从高级REST角度来看,您的品味,客户并不关心您的工作。