セグメント化された/パスIDを持つREST API

Question

リソースが実質的にセグメント数が異なるパス状のアドレスによって識別されるシステム用のREST APIを設計しようとしています。例えば以下のように、 "スキーマ" リソースは、ファイルシステム上で表すことができる：

/リソース/スキーマ/ myFolder2という/ MyFolder5/MySchema27

ファイルシステムパス/リソース/スキーマ/すべてのスキーマのルートフォルダです。これより下のものは、すべてユーザー定義です（フォルダの深さとフォルダの名前まで）。 （単独で「MySchema27」は必ずしも一意ではないため）ので、上記の例では、特定のスキーマが一意に次のアドレスによって識別される。

/myFolder2という/ MyFolder5/MySchema27

REST APIでこのようなリソースを参照する最良の方法は何でしょうか？私は/スキーマコレクションを持っている場合

私のRESTのURLは次のようになります。

/スキーマ/ myFolder2という/ MyFolder5/MySchema27

それは合理的なアプローチでしょうか？これを処理するより良い方法はありますか？

クライアントは、スキーマアドレス（URLパラメータまたはリクエスト本文）を使用してスキーマを検索しなければならない固有のIDを返す必要があります。より伝統的な/スキーマ/ {id}デザインで使用することができます。しかし、私はそれが好きであるとは確信していません。なぜなら、それは各リソースの個別のIDを追跡することを意味するからです。思考？ありがとう。

Answer 1

"フォルダ" /Resources/Schemas/にリソースを追加する通常の方法は、このPOSTリクエストの本文に追加するリソースの表現が含まれているPOSTリクエストを作成してから、サーバーが検索を行います次の無料の{id}と新しいリソースを/Resources/Schemas/{id}に設定します。

もう1つの方法は、/Resources/Schemas/newでGETリクエストを行い、次の空きの{id}を返してから、もう一度/Resources/Schemas/{id}にPUTをリクエストすることです。しかし、この2番目のアプローチは、2つの同時リクエストが同じ新しい{id}を返すことがあり、2番目のPUTが最初のものを消去するため、最初の方法ほど安全ではありません。何らかの予約メカニズムでこれを保護することができます。

Answer 2

これは、RESTサービスを構築するためのリソースベースのURIアプローチと呼ばれます。ビデオチュートリアルのこれらの素晴らしいセットに従って、それらについてさらに理解し、実装する方法も学びます。 https://javabrains.io/courses/javaee_jaxrs