SCIM端点和SCIM中的其他扩展资源 [英] SCIM endpoints and other extended Resources in SCIM

问题描述

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

I had couple of questions regarding the SCIM api endpoints discussed here : http://www.simplecloud.info/specs/draft-scim-api-01.html and I thought this might be a good place to start with.

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

In the specs I see the following :

"SCIM协议指定了众所周知的端点和用于管理核心模式中定义的资源的HTTP方法；即，用户资源和组资源分别对应于/Users和/Groups.支持扩展资源的服务提供者应使用既定的惯例；在扩展模式中定义的资源名称通过添加"s"来进行复数.在某些情况下，资源的复数是模棱两可的；例如，名为人"的资源合法地是人"，而人"消费者应该发现资源端点通过模式子属性'endpoint'.

"The SCIM protocol specifies well known endpoints and HTTP methods for managing Resources defined in the core schema; i.e., User and Group Resources correspond to /Users and /Groups respectively. Service Providers that support extended Resources SHOULD define Resource endpoints using the established convention; pluralize the Resource name defined in the extended schema by appending an 's'. Given there are cases where Resource pluralization is ambiguous; e.g., a Resource named 'person' is legitimately 'persons' and 'people' Consumers SHOULD discover Resource endpoints via the Schema Sub-Attribute 'endpoint'. "

我不理解的是以下内容:

What I don't understand is the following:

1)我以前从未见过资源名称的大写形式.这对SCIM来说是新的吗?默认情况下，浏览器中的网址(该网址随处可见)不区分大小写，无论是否使用大写字母都无关紧要.我真正的问题是将资源"名称大写是规范的一部分还是仅是示例? 2)(这可能更多是REST规范和SCIM之间的网格问题).我们有一个场景，用户有收藏夹".我们可以通过2种方式处理此问题:

1) I have never seen Capitalization of the Resource name before. Is this something new for SCIM? Urls in browsers (urls anywhere for that matter) are by default case insensitive and it doesn't matter if we capitalize it or not. My real question would be is capitalizing the Resource name a part of the spec or just an example? 2) (This might be bit more of a mesh up question between REST spec and SCIM). We have a scenario where a user HAS "favorites". There are 2 ways we can handle this:

/scim/v1/users/{userId}/收藏夹(我们可以称其为扩展子资源)

/scim/v1/users/{userId}/favorites (we can call this an extended sub-resource)

OR

/scim/favorites/users/{userId}(我们可以将所有这些扩展资源收藏夹").

/scim/favorites/users/{userId} (we can all this an extended resource "favorites").

从url角度来看，两者似乎都是正确的，但是我不知道是哪一种符合SCIM(也许是REST?)规范.接下来的问题可能是，扩展的资源是否也必须大写?

From the url perspective both seem to be right but what I don't know is which one is more suitable according to SCIM (and maybe REST? ) specifications. And a follow up question to that might be, do the extended resources have to be capitalized as well?

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

All help is appreciated! I am new to implementing and understanding SCIM, so please forgive me if I have missed some subtle pointers in the specifications itself!

干杯，期待能帮助我理解这一问题的所有答案！

Cheers and looking forward to any answers that can help me understand this!

推荐答案

URL始终区分大小写.但是，主机名不是.

URLs have always been case sensitive. HOST names, however, are not.

http://example.com/User?id=JohnDoe和http://ExAmPlE.cOM/User?id=JohnDoe也应解析为相同的资源.但是网址区分大小写.

http://example.com/User?id=JohnDoe and http://ExAmPlE.cOM/User?id=JohnDoe should resolve to the same resource, even though the URLs are not identical. But the URL is case sensitive.

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

Since the spec is specifying Users rather than users, the casing is significant.

这很重要，因为该规格说明了这一点.另外，如果没有其他要求，则阅读此规范的其他人将使用Users和users.

It's significant because the spec says so. Also, if nothing else, others who read the spec will be using Users vs users.

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

Regarding REST, these URLs wouldn't matter, since REST doesn't care about URLs.

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

But this is not REST. This is an HTTP based specification. It has nothing to do with REST.

附录:

他们可以随心所欲地将其称为REST API，但事实并非如此.他们还称其为"REST协议"，由于REST是一种体系结构，因此没有意义. HTTP是一种协议.您可以在HTTP之上构建REST架构的应用程序，但不必这样做. REST与HTTP无关.

They can call it a REST API all they like, it doesn't make it so. They also call it a "REST protocol", which makes no sense since REST is an architecture. HTTP is a protocol. You can build a REST architected application on top of HTTP, but you don't have to. REST is unrelated to HTTP.

出于相同的原因，REST并不关心URL. REST的一个主要原则是HATEOAS，它实质上是标识资源中的链接并对其进行跟踪.您知道亚马逊的结帐"链接是什么吗?不?但是您仍然设法在那购物吗?这可能是因为您点击结帐"链接，而不是因为您知道URL是什么.

REST doesn't care about URLs for the same reason you don't. A key tenet in REST is HATEOAS, which is essentially identifying links within the resources and following them. Do you know what the "checkout" link is for Amazon? No? Yet you still manage to shop there? That's possible because you follow the "checkout" link, not because you know what the URL is.

REST体系结构中经过适当设计的客户端仅遵循有效负载中为其提供的URL. URL对它来说是不透明的.只需告知客户端该服务的入口点(如果需要，则为主页)，它就可以通过它在有效负载中找到的众所周知的链接标识符(rel)自行从那里导航.

A properly designed client in a REST architecture simply follows the URLs given to it within the payloads. The URLs are opaque to it. The client need only be told of an entry point (the home page if you will) of the service, and it can navigate from there on its own via well know link identifiers (rels) that it finds in the payloads.

该规范几乎没有.

在规范中考虑他们如何说版本控制是可选的.因此，这意味着URL可以是/v1/Users，也可以是/Users.您在客户端中编码哪个URL?您怎么知道某人正在运行哪个版本?如果您所使用的服务之前未进行版本控制而变成了版本，该怎么办?您所有的网址都中断了.如果您想让协议易于在野外实现，请将OPTIONAL元素添加到基础知识中，例如如何访问它.

Consider in the spec how they say that versioning is OPTIONAL. So, that means a URL can be /v1/Users or just /Users. Which URL do you code in your client? How do you know what version someone is running? What if the service you're using was not versioned before and becomes versioned? All of your URLs break. If you want to make a protocol joyous to implement in the wild, add OPTIONAL elements to fundamentals like how to access it.

考虑PATCH部分，他们在其中谈论有关从组中删除用户的问题.他们有:

Consider the PATCH section where they talk about deleting a User from a group. They have:

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

什么是value?看起来像某种用户ID".但是，URL应该是用户ID.是 http://example.com/Users/1234 还是

What is value? Looks like some kind of "user id". Yet, the URL should be the User ID. Whether it's http://example.com/Users/1234 or http://example.com/shippingdepartment/v1/Users/1234 or http://example.com/beta/notforpublication/Users/1234. THAT's a unique identifier. What does simply 1234 tell you? Not enough.

有了HATEOAS，您的客户就不必知道"如何构建"这些URL，而不会出错.服务器告诉客户端这些是什么.

With HATEOAS, your client doesn't have to "know" how to "build" these URLs, and get it wrong. The server tells the client what those are.

当您要获取GET时会发生什么: 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)，甚至是主机(www.example.com到www.beta.example.com) .您的客户怎么会知道如何构建新的URL?

What happens when you want to GET: http://www.example.com/Users/1234 and they changed over to /v2? In REST on HTTP, the server can respond with a 301 Moved Permanently with a Location: http://www.beta.example.com/v2/users/4567/core. The server just told your client that this resource has moved. Not just the "ID" (1234 to 4567), but the path (/Users/1234 to /v2/users/4567/core), and even the HOST (www.example.come to www.beta.example.com). How would your client even know how to build the new URL?

因此，1234还不够.不透明的URL更健壮.就像您不在乎编程中指针的值一样，您也仅关心指针的指向以及指针数学导致更多麻烦的原因.

So, 1234 isn't enough. An opaque URL is much more robust. Just like you don't care what the value of a pointer is in programming, you only care about what it's pointing too, and why pointer math leads to more trouble.

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

And if they used the URL in these Groups, then you could have cross domain User Groups! What a novel idea. You could have v1 and v2 users in the same group. All sorts of things.

对于#2(子资源)和什么不是资源，这是一个问题-从高级REST的角度来看，您的见解使客户不在乎您的工作.

As for #2, sub resources and what not, that's a matter of taste -- your taste, as you can see, from high level REST perspective, clients don't care what you do.

这篇关于SCIM端点和SCIM中的其他扩展资源的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！