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

Question

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

在我看到以下规格：

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

我不明白的是以下几点：前资源名称的

1）我从来没有见过资本。这对SCIM来说是新的吗？浏览器中的Url（就此而言，在任何地方都可以使用）默认情况下是不区分大小写的，如果我们使用它或不使用它，则无关紧要。我真正的问题是将资源名称作为规范的一部分或仅仅是一个例子？ 2）（这可能是REST规范和SCIM之间的一个网格问题）。我们有一个用户有“最爱”的场景。有两种方法可以处理这个问题：

/SCIM/V1 /用户/ {用户id} /收藏夹（我们可以称之为一个扩展子资源）

OR

/SCIM /收藏/ users/{userId}（我们可以将这一切扩展为资源“收藏夹”）。

从URL角度都似乎是正确的，但我不知道是哪一个更适合根据SCIM（也许休息吗？）规格。还有一个后续问题可能是，扩展资源是否也需要资本化？

所有帮助表示赞赏！我是实施和理解SCIM的新手，所以请原谅我，如果我错过了规范本身的一些细微指针！

欢呼和期待任何答案，可以帮助我理解这一点！

Answer 1

网址一直区分大小写。但是，主机名不是。

http://example.com/User?id=JohnDoe和http://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并不关心网址，因为您不会这样做。 REST的一个关键原则是HATEOAS，它主要是识别资源中的链接并遵循它们。你知道亚马逊的“结帐”链接是什么吗？没有？但你仍然设法在那里购物？这是可能的，因为你按照“结帐”链接，而不是因为你知道网址是什么。

在REST体系结构中正确设计的客户端只需遵循在有效内容中提供给它的URL。这些网址对此不透明。客户端只需告知服务的入口点（如果您愿意的话），并且可以通过它自己的导航点，通过它在有效载荷中找到的已知链接标识符（rels）进行导航。

该规范几乎没有。

在规范中考虑他们如何说版本控制是可选的。所以，这意味着URL可以是/ v1/Users或者只是/ Users。你在你的客户端编码了哪个URL？你怎么知道某人正在运行的版本？如果您使用的服务之前未经过版本控制并变为版本控制，该怎么办？您的所有网址都会中断。如果你想让一个协议在野外实现，可以将OPTIONAL元素添加到基础知识中，比如如何访问它。

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

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

什么是value？看起来像某种“用户ID”。但是，该网址应该是用户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），还有路径（/ Users/1234到/ v2/users/4567/core），甚至是HOST（www.example.come到www.beta.example.com） 。您的客户如何知道如何构建新的URL？

因此，1234是不够的。一个不透明的URL更健壮。就像你不在乎指针在编程中的价值是什么一样，你只关心它指向的是什么，指针数学为什么会导致更多的麻烦。

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

至于＃2，子资源和什么不是，这是一个品味的问题 - 你的品味，从高层次的REST角度来看，客户不关心你在做什么。