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 の間のメッシュアップの問題かもしれません)。ユーザーが「お気に入り」を持っているシナリオがあります。これを処理するには 2 つの方法があります。

/scim/v1/users/{userId}/favorites (これを拡張サブリソースと呼ぶことができます)

また

/scim/favorites/users/{userId} (これをすべて拡張リソース「お気に入り」にすることができます)。

URL の観点からはどちらも正しいように見えますが、SCIM (およびおそらく REST?) 仕様に従って、どちらがより適しているかはわかりません。それに対するフォローアップの質問は、拡張されたリソースも資本化する必要があるかということです。

すべての助けに感謝します！私は SCIM の実装と理解に慣れていないため、仕様自体の微妙な指針を見逃していた場合はご容赦ください。

これを理解するのに役立つ回答をお待ちしております。

4

1 に答える 1

3

URL では常に大文字と小文字が区別されます。ただし、HOST 名はそうではありません。

http://example.com/User?id=JohnDoehttp://ExAmPlE.cOM/User?id=JohnDoeURL が同一でなくても、同じリソースに解決されるはずです。ただし、URL は大文字と小文字が区別されます。

Usersではなくスペックを指定しているため、大文字users小文字が重要です。

仕様がそう言っているので、それは重要です。また、他に何もないとしても、仕様を読んだ他の人はUsersvsを使用しusersます。

REST に関しては、REST は URL を気にしないため、これらの URL は重要ではありません。

しかし、これは REST ではありません。これは HTTP ベースの仕様です。REST とは関係ありません。

補遺:

好きなように REST API と呼ぶことができますが、そうはなりません。彼らはそれを「REST プロトコル」とも呼んでいますが、REST はアーキテクチャであるため意味がありません。HTTP はプロトコルです。HTTP の上に REST で設計されたアプリケーションを構築できますが、そうする必要はありません。REST は HTTP とは無関係です。

あなたが気にしないのと同じ理由で、REST は URL を気にしません。REST の重要な原則は HATEOAS です。これは基本的に、リソース内のリンクを識別し、それらをたどることです。Amazonの「チェックアウト」リンクが何であるか知っていますか? いいえ？それでも、あなたはまだそこで買い物をすることができますか？これは、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 を「構築」する方法を「知っている」必要はなく、間違って取得する必要もありません。サーバーはクライアントにそれらが何であるかを伝えます。

http://www.example.com/Users/1234を GET したいときに、/v2 に変更した場合はどうなりますか? 301 Moved PermanentlyREST on HTTP では、サーバーはLocation: 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 に答える