Linked Web Storageプロトコル 1.0

LWSプロトコルは、ある主体が何らかのリソースを何らかのエージェントに利用可能にできる標準的なやり取りを定義する。

• 提供リソース - (利用可能なリソース? 公開された リソース?) (UCSで 定義されていない) この文書で定義されるプロトコルを用いたやり取り、 取得、または操作のためにサービスによって公開される、ネットワークアクセス可能な実体。
• 要求エージェント - (UCSにおける実体) 提供可能なリソースとやり取りする要求を開始する実体 （例: クライアント、ユーザー、またはプロセス）。

リソース管理者は、提供リソースを 非公開に保つことも、誰にでも公開することも、その可視性を制約された一群の 要求エージェントに限定することもできる。

• 認証 - 要求を実行するエージェントの身元を検証するプロセス。
• 認可 - エージェントが特定の リソースにアクセスする、または一連の操作のいずれかを実行する権限を持つかどうかを判定するプロセス。
• リソース 管理者 - (UCSにおけるcontroller) 提供リソースへのアクセスを制御する権限を持つエージェント。

非規範的と明示された節に加え、この仕様におけるすべての作成ガイドライン、図、例、および注記は 非規範的である。この仕様のそれ以外のすべては規範的である。

この文書におけるキーワードMAY、MUST、MUST NOT、OPTIONAL、RECOMMENDED、REQUIRED、SHOULD、およびSHOULD NOTは、 ここに示すようにすべて大文字で現れる場合に限り、 BCP 14 [RFC2119] [RFC8174] に記述されるとおりに解釈される。

LWSサーバーは、この仕様における関連するすべての「MUST」 文に適合するHTTPサーバー[rfc9112]である。具体的には、 この文書の9. 操作における関連する規範的な「MUST」文を尊重MUSTする。

LWS クライアントは、この仕様における関連するすべての「MUST」文に適合するHTTPクライアント[rfc9112]である。具体的には、この文書の9. 操作における関連する規範的な 「MUST」文をMUST尊重する。

次の図は、実装の指針となる プラットフォーム非依存のモデルである。

この節で記述されるデータモデルは、認証資格情報の任意の 具体的なシリアル化に対する要件を概説する。

認証資格情報は、主体に関する改ざん明示的なクレームを含まなければMUSTならず、これには次が含まれる:

• 主体 REQUIRED — エンドユーザーの識別子。これはURIでなければMUSTならない。
• 発行者 REQUIRED — 認証資格情報を発行した実体の識別子。これはURIでなければMUSTならない。
• クライアント REQUIRED — クライアントアプリケーションの識別子。これは URIであるべきSHOULDである。
• オーディエンス 制限 RECOMMENDED — 認可サーバー識別子を含むべきSHOULD 値の一覧。

認証資格情報の検証には、検証者と資格情報の発行者との間の信頼 関係が必要である。この信頼関係は、アウトオブバンドのメカニズムを通じて確立されてもMAYよい。 検証者と発行者との間の信頼を確立するための追加メカニズムは、特定の認証スイートで概説される。

認証資格情報は署名されなければMUSTならない。署名には非対称暗号を用いることがRECOMMENDEDされる。

各認証スイートは、トークン型URIに関連付けられなければMUSTならない。 認証スイートは、IANA「OAuth URI」レジストリで定義されたURIを使用すべきSHOULDである。

LWS認可における役割は、OAuth 2.0の1.1節[RFC6749]で定義されているものと同じである： リソース所有者、 リソースサーバー、 クライアント（曖昧さを避けるため、この仕様では認可クライアントと 呼ぶ）、および 認可サーバー。 ストレージサーバーは、LWSストレージ仕様にも適合するリソースサーバーの一種である。

この仕様は、クライアントと認可サーバーとの間のやり取り、および クライアントと適合ストレージサーバーとの間のやり取りを記述する。

認可サーバーとストレージサーバーとの間のやり取りは、この仕様の範囲外である。 認可サーバーはストレージサーバーと同じサーバーであってもよく、別個の実体であってもよい。

HTTP/2 401 Unauthorized
Link: <https://storage.example/storage_1>; rel="https://www.w3.org/ns/lws#storage"
WWW-Authenticate: Bearer as_uri="https://authorization.example",
                realm="https://storage.example/storage_1",
                error="invalid_token"

{
    "issuer": "https://authorization.example",
    "grant_types_supported": [
        "urn:ietf:params:oauth:grant-type:token-exchange"],
    "token_endpoint": "https://authorization.example/token",
    "jwks_uri": "https://authorization.example/jwks",
    "claims_supported": [
        "sub",
        "iss",
        "client_id",
        "aud"],
    "response_types_supported": [
        "token"],
    "subject_token_types_supported": [
        "urn:ietf:params:oauth:token-type:jwt",
        "urn:ietf:params:oauth:token-type:id-token"]
}

POST /token HTTP/1.1
Host: authorization.example
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&resource=https%3A%2F%2Fstorage.example%2Fstorage_1
&subject_token=eyJ0eXAiOiJhcytqd3QiLCJhbGciO...fiK51VwhsxJ-siBMR-YFiA
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aid_token

HTTP/1.1 200 OK
Content-Type: application/json

{
    "access_token":"eyJ0eXAiOiJhcytqd3QiLCJhbGciOiJFUzI1NiIs...DeWt4QuZXso",
    "token_type":"Bearer",
    "expires_in":3600
}

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
    "error":"invalid_request"
}

{
  "kid": "ec51c6b2",
  "kty": "EC",
  "alg": "ES256",
  "crv": "P-256",
  "typ": "at+jwt"
}
.
{
  "sub": "https://id.example/agent",
  "iss": "https://authorization.example",
  "client_id": "https://app.example/id",
  "aud": "https://storage.example",
  "exp": 1735686300,
  "iat": 1735686000,
  "jti": "550e8400-e29b-41d4-a716-446655440000"
}
.
signature

Authorization: Bearer eyJ0eXAiOiJhcytqd3QiLCJhbGciOiJFUzI1NiIs...DeWt4QuZXso

ストレージ記述リソースは、クライアントが ストレージとやり取りする際に使用できる情報を提供し、 機能およびサービスエンドポイントの記述を含む。

{
  "@context": [
    "https://www.w3.org/ns/cid/v1",
    "https://www.w3.org/ns/lws/v1"
  ],
  "id": "https://storage.example/",
  "type": "Storage",
  "service": [{
    "type": "StorageRoot",
    "serviceEndpoint": "https://storage.example/root/"
  }]
}

{
  "@context": [
    "https://www.w3.org/ns/cid/v1",
    "https://www.w3.org/ns/lws/v1"
  ],
  "id": "https://storage.example/",
  "type": "Storage",
  "capability": [{
    "type": "https://feature.example/PatchSupport",
    "format": {
      "text/turtle": ["application/sparql-update"],
      "application/n-triples": ["application/sparql-update"],
      "application/linkset+json": ["application/merge-patch+json", "application/json-patch+json"]
    }
  }, {
    "type": "https://feature.example/ResumableUploads"
  }, {
    "type": "https://feature.example/ContentNegotiation",
    "source": "application/ld+json",
    "target": ["text/turtle", "application/n-triples"]
  }, {
    "type": "https://feature.example/ContentNegotiation",
    "source": "image/jpeg",
    "target": ["image/png"]
  }],
  "service": [{
    "type": "StorageRoot",
    "serviceEndpoint": "https://storage.example/root/"
  }, {
    "type": "NotificationService",
    "serviceEndpoint": "https://storage.example/notification/api",
    "subscriptionType": ["WebhookSubscription"]
  }, {
    "type": "TypeIndexService",
    "serviceEndpoint": "https://storage.example/types/index"
  }, {
    "type": "TypeSearchService",
    "serviceEndpoint": "https://storage.example/types/search"
  }, {
    "type": "DataSharingService",
    "serviceEndpoint": "https://storage.example/sharing/api"
  }]
}

リンクトウェブストレージは、リソースをコンテナーに編成します。コンテナーは、 メンバーと呼ばれる他のリソースへの参照を保持する特殊なリソースです。コンテナーは、 ディレクトリーやコレクションに類似した編成単位として機能し、クライアントがリソースをグループ化、検出、 およびナビゲートできるようにします。コンテナーは、そのメンバーリソースへの参照を維持します。 メンバーリソースには、非コンテナーリソースと追加のコンテナーリソースの両方を含めることができ、それによって 階層構造を形成できます。通常、コンテナーが保持する固有の内容は、 メタデータまたはそのメンバーの列挙を除けば最小限であり、その主な役割は、下位のリソースを集約して 構造化することです。ストレージシステムのルートは、上位の親を持たない 最上位の編成単位として機能するコンテナーとして指定されます。コンテナー表現の構造は、8.1 コンテナー 表現で定義され、そのメディアタイプおよびページネーション要件は、12. LWSメディアタイプで定義されます。 ストレージは、ルートコンテナーとして機能してもよく、直接書き込みを可能にします。

すべてのLWSストレージには、最上位の編成単位として機能するストレージ ルートがあります。ストレージルートには親がなく、ストレージ 階層へのエントリーポイントとして機能します。

LWS内のリソースは、次のいずれかに分類される:

• コンテナ — 他の リソースを含むリソース。
• データリソース — データを保持するリソース （例: 文書、画像、または構造化データファイル）。

リソースとその親コンテナとの間の包含関係は、rel="up"リンク 関係によって表現される。サーバーは、任意の 非ルートリソースに対するGETおよびHEAD要求への応答において、親コンテナを指す rel="up"を持つLinkヘッダーを含めなければMUSTならない。

Link: </alice/notes/>; rel="up"

コンテナのメンバーは、その表現内で itemsプロパティを用いて一覧化される。サーバーがこの一覧を管理するため、クライアントは直接変更できない。 メンバーシップの変更は、リソースの作成および削除の副作用として発生する。

サーバーは、常に包含の完全性を維持しなければMUSTならない:

• 作成: 新しいリソースがコンテナ内に作成される場合、 サーバーは、そのリソースをコンテナの items一覧に原子的に追加しなければMUSTならない。
• 削除: リソースが削除される場合、サーバーは それを親コンテナのitems一覧から 原子的に削除しなければMUSTならない。 コンテナを削除するには、再帰的削除が明示的に要求されない限り、 コンテナが空である必要がある。
• 孤立なし: すべての非ルートリソースは、ストレージルートから包含 階層を通じて到達可能でなければMUSTならない。
• 循環なし: コンテナは、自身を直接または 間接的に含んではMUST NOTならない。

リソースはURIによって識別されます。リソースのURIは、包含階層内の位置から独立しています。サーバーはリソースの 作成時にURIを割り当て、クライアントヒントを組み込んでもよいものとしますが、クライアントはURI構造が包含を反映していると仮定すべきではありません。

包含関係は、URIパス構造ではなく、メタデータ （rel="up"リンクおよびコンテナ 表現内のitemsプロパティ）を通じて表現される。この分離により、明確に定義された編成モデルを維持しながら、 サーバーはURI割り当てに柔軟性を持てる。

クライアントがコンテナへの読み取りアクセス権を持つ場合、 コンテナ 表現は、そのコンテナに含まれるリソースのうち、 クライアントがアクセス権を持つすべてのリソースの識別子を含まなければMUSTならない。また、そのコンテナに含まれるリソースのうち、クライアントがアクセス権を持たないリソースの識別子を 含んでもMAYよい。

クライアントがコンテナ一覧を読み取れることは、含まれる リソース自体へのアクセス権を意味せず、その逆も同様である。

クライアントが コンテナーを取得すると、サーバーは、その コンテナーおよびその内容を記述する、構造化された コンテナー表現を返す。この節では、コンテナー表現の必須および オプションのプロパティを定義する。

{
  "@context": "https://www.w3.org/ns/lws/v1",
  "id": "/alice/notes/",
  "type": "Container",
  "totalItems": 2,
  "items": [
    {
      "type": "DataResource",
      "id": "/alice/notes/shoppinglist.txt",
      "format": "text/plain",
      "size": 47,
      "modified": "2025-11-24T12:00:00Z"
    },
    {
      "type": ["DataResource", "http://example.org/customType"],
      "id": "/alice/notes/todo.json",
      "format": "application/json",
      "size": 2048,
      "modified": "2025-11-24T13:00:00Z"
    }
  ]
}

この節では、メタデータをLWSリソースに関連付けるためのモデルを定義します。 LWSメタデータシステムは、型付きリンクを使用してサーバーがリソース間の関係を記述できる ウェブリンク [RFC8288] の原則に基づいています。 メタデータは検出可能性を高め、自己記述型APIをサポートし、リソース操作およびコンテナー階層と整合します。

メタデータモデル LWS内のすべてのメタデータは、リソース（リンクコンテキスト）を起点とする型付きリンクの集合として表現されます。 各リンクは、次の要素で構成されます。

• リンクターゲット：関連リソースを識別するURI。
• 関係タイプ：関係の性質を定義する文字列。
• 任意のターゲット属性：リンクまたはターゲット リソースをさらに記述する追加のキーと値のペア。

メタデータはリソースとその表現を区別し、該当する場合には複数のメディアタイプを 使用できるようにします。データリソースの場合、メタデータには表現が含まれ、各表現は formatおよび任意のsizeInBytesを持ちます。コンテナーおよびデータリソースでは、親コンテナーリソースへのリンクを、そのリソースのメタデータの一部と見なします。

リンクセットリソース ストレージ内の各リソースについて、サーバーは必ずメタデータリンクを、 [RFC9264]に従って独立したリソースとして利用可能にしなければなりません。

• 検出：リソースのリンクセットは、関係 rel="linkset"を持つLinkヘッダーを介して検出できます。
• メディアタイプ：リンクセットリソースは、必ず application/linkset+jsonとして利用可能でなければなりません。
• 整合性：'linkset'リンクは、必ずサーバーによって管理されるリソースを指さなければなりません。 一貫性を維持するため、リンクセットの更新は、必ず関連するリソース操作と アトミックでなければなりません。

メタデータの検出 クライアントは、主にGETまたはHEAD要求への応答に含まれるLinkヘッダーを通じてメタデータを検出します。

• ストレージ：サーバーは、関連する応答に必ず rel="https://www.w3.org/ns/lws#storage"を持つLinkヘッダーを含めなければなりません。
• 包含：サーバーは、ルート以外のすべてのリソースについて、親コンテナーを指す rel="up"を持つLinkヘッダーを必ず含めなければなりません。
• プリファレンス：クライアントは、特定の関係を含めるか省略するために、URI https://www.w3.org/ns/lws#PreferLinkRelationsとともにPreferヘッダー [RFC7240]を使用してもよいものとします。

メタデータの種類

変更可能性に関する考慮事項 コアメタデータは、クライアントによって変更してもよいものとします。相互運用性を確保するため、サーバーは、 必ず標準HTTPヘッダーを使用して、その能力を通知しなければなりません。

1. メソッドの検出：サーバーは、Allowヘッダーを介して、リンクセットリソースに対するGETおよびPATCH 操作のサポートを必ず通知しなければなりません。

2. パッチ形式の検出：サーバーは、Accept-Patchヘッダーを介してJSONマージ パッチ [RFC7386] のサポートを必ず通知しなければなりません。 Accept-Patch: application/merge-patch+json。

3. 任意のメソッド：サーバーは、任意でPUTまたは代替のパッチ形式をサポートできます。 サポートする場合、それらは必ずそれぞれAllowヘッダーおよびAccept-Patch ヘッダーに含まれなければなりません。

[!IMPORTANT] クライアントは、リソースヘッダーで通知されていない限り、PUTまたは特定のパッチ形式のサポートを仮定すべきではなく、 405 Method Not Allowedまたは415 Unsupported Media Type応答を必ず適切に処理しなければなりません。

メタデータの管理 メタデータは、リソースに関連付けられたリンクセットリソース URIとやり取りすることによって管理されます。サーバーは、更新の同時実行制御を必ずサポートしなければなりません。

• 部分更新（PATCH）：これは、メタデータ管理の主要なメカニズムです。サーバーは、必ずapplication/merge-patch+jsonを使用するPATCHをサポートしなければなりません。

• 置換（PUT）：Allowヘッダーで通知されている場合、クライアントはリンクセット全体を置換してもよい ものとします。サーバーがPUTをサポートしない場合、必ず 405 Method Not Allowedで要求を拒否しなければなりません。

• 制限：サーバーは、システムの整合性を維持するため、upや itemsなどの特定のリンクに対する変更を制限してもよいものとします。

• ライフサイクル：メタデータのライフサイクルは、記述対象のリソースに結び付けられます。リソースを削除すると、必ず、関連付けられたリンクセットリソースのメタデータが自動的に削除されなければなりません。

リソースを作成する操作は、新しい提供リソースを既存のコンテナに追加する。この 操作は、データリソースおよびサブコンテナの作成の両方を扱う。

入力:

• 対象コンテナ: 新しいリソースが作成されるコンテナの識別子。
• 識別子ヒント: 新しいリソースの識別子に対する任意の提案。サーバーは このヒントを使用してもよいが、使用を要求されない。
• コンテンツ: 新しいリソースの初期コンテンツおよび型。

振る舞い:

• 識別子生成: サーバーは、新しい リソースの最終的な識別子（URI）を決定する。識別子ヒントが提供された場合、サーバーは、 コンテナ内での 一意性および妥当性を確保しながら、それを取り込もうとする。ヒントが提供されない場合、サーバーは 一意な識別子を生成する。
• コンテナメンバーシップ更新: サーバーは、新しいリソースを 対象コンテナのメンバーシップ一覧に原子的に追加する。
• メタデータ初期化: サーバーは、新しい リソースのシステムメタデータを初期化する。リソースに関連付けられたメタデータリソースがある場合、それも 初期化される。

可能な応答:

• 作成済み: 操作は成功した。サーバーは、新しく作成されたリソースの最終的な 識別子を返す。
• 対象が見つからない: 指定された対象コンテナは存在しない。
• 許可されていない: クライアントの身元は既知であるが、このコンテナにリソースを作成する権限がない。
• 不明な要求者: サーバーはクライアントの身元を認識せず、 認証を必要とする。
• 競合: 生成された識別子を持つリソースが既に存在する、または 別の状態競合がある。
• 不明なエラー: 予期しない内部エラーが発生した。

新しいリソースは、対象となるコンテナーURIに対してPOSTを使用して作成され、サーバーが 最終的な識別子を割り当てます。クライアントは、RFC8288のウェブリンク構文に従い、POST要求に1つ以上の Linkヘッダーを含めることで、新しいリソースに初期のユーザー管理メタデータを任意で提供できます。 [RFC8288]。サーバー管理メタデータは、必ず 作成時にサーバーによって自動的に生成され、クライアントが提供したリンクによって決して 上書きされてはなりません。

成功時、サーバーは、Locationヘッダーに新しいURIを指定して、201ステータスコードを必ず返さなければなりません。 サーバーは、親コンテナーへのリンク （rel="up"）や、作成されたリソース専用のリンクセットリソースへのリンク （rel="linkset"; type="application/linkset+json"）を含む、主要なサーバー管理メタデータ用の Linkヘッダーを必ず含めなければなりません。追加のリンクには、原則としてrel="type"を含めるべきです（ https://www.w3.org/ns/lws#Containerまたは https://www.w3.org/ns/lws#DataResourceを示します）。本文は、任意で空にするか、 リソースの最小限の表現を含めることができます。一貫性を維持するため、すべてのメタデータの作成およびリンクは、 リソースの作成と必ずアトミックでなければなりません。

POST（コンテナーURIに対して） – サーバーが割り当てた名前で作成： POSTを使用して、既存のコンテナー内に新しいリソースを追加します。サーバーがリソースの 識別子を割り当てます。クライアントは、作成するリソースの種類を次のように示します。

• コンテナーを作成するには、クライアントは、Containerタイプを指す rel="type"を持つLinkヘッダーを必ず含めなければなりません。 Link: <https://www.w3.org/ns/lws#Container>; rel="type"。
• データリソースを作成するには、クライアントは、適切な Content-Typeヘッダーとともに、要求本文にリソースの内容を含めます。

例（POSTによる新しいデータリソースの作成）：

POST /alice/notes/ HTTP/1.1
Host: example.com
Authorization: Bearer <token>
Content-Type: text/plain
Content-Length: 47

milk
eggs
bread
butter
apples
orange juice

この例では、クライアントはコンテナー/alice/notes/にPOSTしています。 クライアントはtext/plainの内容（買い物リスト）を提供し、新しいリソースの名前として shoppinglist.txtを提案します。/alice/notes/が存在し、クライアントが 認可されている場合、サーバーは新しいデータリソースを作成し、コンテナーのメンバーに追加します。

例（POSTへの応答 — データリソース）：

HTTP/1.1 201 Created
Location: /alice/notes/shoppinglist.txt
Content-Type: text/plain; charset=UTF-8
Link: </alice/notes/shoppinglist.txt.meta>; rel="linkset"; type="application/linkset+json"
Link: </alice/notes/>; rel="up"
Link: <https://www.w3.org/ns/lws#DataResource>; rel="type"
Content-Length: 0

成功時には、Locationヘッダーに新しいURIを指定して201 Createdを返します。本文は、 空または最小限の表現にできます。 対象となるコンテナー/alice/notes/が存在しない場合、別のステータスコードの方が適切でない限り、サーバーは 必ず404エラーステータスを返さなければなりません。

コンテナーの作成：新しいコンテナーを作成するには、クライアントは、Containerタイプを示す Linkヘッダーとともに、既存の親コンテナーに対してPOSTを使用します。例：

POST /alice/ HTTP/1.1
Host: example.com
Authorization: Bearer <token>
Content-Length: 0
Link: <https://www.w3.org/ns/lws#Container>; rel="type"

例（POSTへの応答 — コンテナー）：

HTTP/1.1 201 Created
Location: /alice/notes/
Link: </alice/notes/.meta>; rel="linkset"; type="application/linkset+json"
Link: </alice/>; rel="up"
Link: <https://www.w3.org/ns/lws#Container>; rel="type"
Content-Length: 0

これにより、/alice/notes/に新しいコンテナーが作成され、サーバーによって生成される メタデータには、https://www.w3.org/ns/lws#Containerとしてのrel="type"が含まれます。

作成に関する追加の注記（HTTPバインディング）：

• POSTは冪等ではありません。繰り返すと重複が作成される可能性があるため、クライアントは原則として 意図しない再試行を避けるか、それを防止するために一意の識別子または検査を使用すべきです。
• メタデータの更新はアトミックです。サーバーは、成功応答を返す前に、リンクセットリソースが作成され、必須の サーバー管理フィールドが設定されていることを必ず保証しなければなりません。
• 検出可能性のため、サーバーは、ハードコードされたURIを持たないクライアントを誘導するために、401応答に rel="https://www.w3.org/ns/lws#storage"を持つLinkヘッダーを原則として含めるべきです。

メタデータの管理および取得（作成に関連）： メタデータは主に読み取り操作によって取得されますが、作成時に生成されます。クライアントは、 作成直後に、新しいリソースURIに対してGETまたはHEADを使用してメタデータを取得できます。クライアントは、 特定のメタデータリンク（関係タイプを介して）および属性を含めるよう要求するために、 Preferヘッダーを使用できます。

既存リソースの表現、またはコンテナの一覧を取得する。

• 入力: 対象識別子および任意のパラメーター。
• 振る舞い:
  • 非コンテナリソースについて、サーバーはリソースコンテンツを返す。
  • コンテナについて、サーバーはメンバー リソースの一覧を返す。この一覧は認可に基づいてフィルタリングされてもMAYよい。一覧は 各メンバーの中核メタデータを含まなければならない。
• 結果: 要求された表現または失敗の通知。

リソースを読み取る操作は、HTTP GET要求（およびヘッダーのみの要求のためのHEAD）で リソース表現を要求する。振る舞いは、対象URLがコンテナであるか、非コンテナリソース（データリソース）であるかにより異なる。サーバーはメタデータを介して リソース型を区別しなければMUSTならない。すべての応答は、 rel="linkset"、rel="up"、およびrel="type"などの主要な関係のLinkヘッダーを含め、 第8.1節で定義されるメタデータと統合されなければMUSTならない。サーバーは、読み取り中にリソース状態とそのメタデータとの原子性を保証しなければMUSTならない。

GET（非コンテナリソース） – リソースのコンテンツを取得: 完全なコンテンツ（認可されている場合）を得るために、リソースURIへGETを送信する。200 OKで応答し、本文には データを含め、Content-Typeは保存されたメディア型に一致する。サーバーは、部分 取得のために[RFC7233]に従う範囲要求をサポートしなければMUSTならない。応答は、同時実行制御および キャッシュのためにETagヘッダーを含まなければMUSTならない。

例（ファイルをGETする）:

GET /alice/notes/shoppinglist.txt HTTP/1.1
Authorization: Bearer <token>
Accept: text/plain

これは、/alice/notes/shoppinglist.txtのコンテンツを要求し、クライアントが テキスト形式で望むことを示している。リソースが存在し、テキストであり、クライアントがアクセス権を持つと仮定すると:

HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
Content-Length: 34
ETag: "abc123456"
Link: </alice/notes/shoppinglist.txt.meta>; rel="linkset"; type="application/linkset+json"
Link: </alice/notes/>; rel="up"
Link: <https://www.w3.org/ns/lws#DataResource>; rel="type"

milk
cheese
bread
guacamole
soda
chocolate bars
hash
eggs

サーバーは、テキストコンテンツ（Content-Lengthで示されるとおり合計34バイト）を返した。 コンテンツは、ファイルに保存されたデータそのものである。ETag: "abc123456"は、キャッシュまたは同時実行のための バージョン識別子である。応答には、メタデータの発見可能性のためのLinkヘッダーが含まれ、 upおよびtypeなどの必須フィールドを伴う。

GET（コンテナリソース） – コンテナの内容を一覧化: 対象URIがコンテナ（メタデータ型により判定）に対応する場合、GET要求は コンテナのメンバー一覧を返す。応答本文は、LWSコンテナメディア 型を使用する、コンテナ表現節で定義されるコンテナ表現である。 一覧には、各メンバーのメタデータが含まれる: リソース識別子（MUST）、型（MUST）、メディア型（DataResourcesについてはMUST）、サイズ（SHOULD）、および 変更タイムスタンプ（SHOULD）。

例（コンテナをGETする）:

GET /alice/notes/ HTTP/1.1
Authorization: Bearer <token>
Accept: application/lws+json

コンテナが存在し、クライアントがアクセス権を持つと仮定すると:

HTTP/1.1 200 OK
Content-Type: application/lws+json
ETag: "container-etag-789"
Link: </alice/notes/.meta>; rel="linkset"; type="application/linkset+json"
Link: </alice/>; rel="up"
Link: <https://www.w3.org/ns/lws#Container>; rel="type"

{
  "@context": "https://www.w3.org/ns/lws/v1",
  "id": "/alice/notes/",
  "type": "Container",
  "totalItems": 2,
  "items": [
    {
      "type": "DataResource",
      "id": "/alice/notes/shoppinglist.txt",
      "format": "text/plain",
      "size": 47,
      "modified": "2025-11-24T12:00:00Z"
    },
    {
      "type": ["DataResource", "http://example.org/customType"],
      "id": "/alice/notes/todo.json",
      "format": "application/json",
      "size": 2048,
      "modified": "2025-11-24T13:00:00Z"
    }
  ]
}

この例では、/alice/notes/はコンテナである。応答は LWSコンテキストを持つJSON-LDを使用し、必須メタデータを持つメンバーを一覧化する。各項目は、 フラットなプロパティとしてtype、 id、format、size、およびmodifiedタイムスタンプを含む。

すべての場合において、サーバーは応答 ヘッダーに次のメタデータを含めなければMUSTならない: ETag（メンバーシップ変更時に変化する一覧バージョンを表す）、 それがコンテナであることを示すrel="type"を持つLink ヘッダー、rel="linkset"および rel="up"。

HEAD（任意のリソースまたはコンテナ） – ヘッダー/メタデータのみ: LWSサーバーは、コンテナおよび非コンテナの両方についてHEAD [RFC9110]をサポートしなければMUSTならず、 GETと同じヘッダー（ETag、Content-Type、メタデータ用Linkを含む）を返すが、本文は返さない。これにより、コンテンツを 転送することなくメタデータ取得が可能になる。

キャッシュおよび条件付き要求: LWSはHTTPキャッシュ意味論を活用する。サーバーは If-None-Match（ETag付き）または If-Modified-Sinceヘッダーを介する条件付き要求をサポートしなければMUSTならない。リソースまたはコンテナ一覧が変更されていない場合、冗長な転送を避けるために 304 Not Modifiedで応答する。ETagは、同時実行およびキャッシュサポートのために、 すべてのGET/HEAD応答で提供されなければMUSTならない。

発見可能性と認可: 発見可能性を高めるため、サーバーは、 クライアントをハードコードされたURIなしで導くパラメーターを持つWWW-Authenticateヘッダーを401 Unauthorized応答に 含めるべきSHOULDである。該当する場合、メタデータリンクも含めるべきSHOULDである。

完全置換または部分パッチを介して、既存の[提供リソース]の状態を変更する。

• 入力: 対象識別子、新しいコンテンツ、および任意の同時実行制約。
• 振る舞い: サーバーは変更を原子的に適用する。同時実行制約が 提供されている場合、リソースが要求者により最後に読み取られて以降に変更されているとき、更新は拒否される。
• 結果: 更新の確認または競合の通知。

リソースを更新するは、 PUT要求（リソース全体を置換するため）またはPATCH要求（部分的な 変更を適用するため）によって、既存の提供 リソースの内容を変更する。クライアントは、これらの 操作を実行するために、リソースのURLへの書き込みアクセス権を持っていなければならない。 注記: この節は、リソースの主要コンテンツの更新について記述する。そのメタデータを更新するには、第 9.3.2節を参照。 LWSサーバーは、リソースURI上のPUTおよびPATCH要求を、リソースコンテンツのみへの 変更として扱わなければMUSTならず、関連付けられたリンクセットリソースへの既定の影響を持たない。任意で、コンテンツと メタデータの両方を単一の原子的操作で更新するために、クライアントはリソースURIへの PUT/PATCH要求にLinkヘッダーを含め、プリファレンス'Prefer: set-linkset'（ RFC 7240で定義）を指定してもMAYよい。この場合、サーバーは、提供されたLinkヘッダーを コンテンツ変更の適用に加えて、リンクセットへの置換（PUTの場合）または部分更新（PATCHの場合）として解釈しなければMUST ならない。この振る舞いはサーバーにとってOPTIONALであるが、サポートされる場合、 意図しないメタデータ上書きを防ぐために、Preferヘッダーを介して明示的に呼び出されなければMUSTならない。結合更新をサポートしないサーバーは、 そのプリファレンスを無視するか、501 Not Implementedで応答しなければMUSTならない。

PUT（リソース全体の置換） – 新しい完全なコンテンツを 本文に含め、一致するContent-Type（通常は既存型と整合）を持つPUTをリソースURIへ送信する。PUTは既存 リソースに対して冪等である。安全のため、現在のETagを持つIf-Matchを含める（第7.3節の同時実行に従う）。不一致は 412 Precondition Failedまたは409 Conflictを生じる。検査なしでは更新は無条件だが、 同時変更を上書きする危険がある。サーバーがリソースについてEtagsをサポートする場合、サーバーは If-Matchヘッダーを欠く無条件PUT要求を428 Precondition Required応答で拒否しなければMUSTならない。

例（リソースを更新するPUT）:

PUT /alice/personalinfo.json HTTP/1.1
Authorization: Bearer <token>
Content-Type: application/json
If-Match: "abc123456"
{
"name": "Alice",
"age": 30,
"city": "New London",
"state": "Connecticut"
}

この例では、クライアントは/alice/personalinfo.jsonにある既存のJSONリソースを更新している。 以前のGETまたはHEAD要求から取得したETag "abc123456"を持つIf-Matchヘッダーを含めている。 サーバーはそれを現在のETagと比較する。一致する場合、提供されたJSONでコンテンツを置換する。 一致しない場合、サーバーは更新を拒否する（その間に他者によってリソースが変更されたため）。 成功応答: 更新が成功した場合、サーバーは200 OKで応答し、 更新された表現または何らかの確認（新しいコンテンツまたはその一部など）を含めてもよい。あるいは、 サーバーは、本文なしで成功を示すために204 No Contentで応答してもよい（特に追加情報を伝える必要がない場合によく使われる）。 いずれの場合でも、サーバーは新しいバージョンを示す新しい ETagを含めるべきSHOULDであり、本文が返される場合はContent-Typeも含めてもよい。例:

HTTP/1.1 204 No Content
ETag: "def789012"

これは、更新が完了したことをクライアントに知らせ、新しいETagを提供する。サーバーが 更新されたコンテンツを返すことを選択した場合、200 OKを使用して本文にJSONを含め、 ヘッダーも伴うことができる。

• エラー応答: If-Matchが一致しなかった場合（同時 変更）、サーバーは412 Precondition Failed（前提条件ヘッダーが失敗したことを意味する）または 409 Conflictを返すことができる。上記の抽象的記述では同時実行の問題に Conflictを使用しており、409はそのシナリオに対する自然なマッピングである。リソースが存在しない場合、 更新としてのPUTは404 Not Foundになる（意図が作成である場合を除くが、通常クライアントは、自分が何をしているか確実な場合にのみ PUTを作成に使用するか、またはIf-Matchなしのupsertとして使用する）。クライアントが認可されていない場合は 403 Forbidden（または有効な認証情報が提供されていない場合は401 Unauthorized）。要求ペイロードが有効でない場合は 400 Bad Request。

PATCH（部分更新） – HTTP PATCHメソッド[RFC5789]は、 クライアントがリソース全体の新しいコンテンツを送信するのではなく、部分的な変更を指定できるようにする。 これは、全体コンテンツを送信することが非効率な大きなリソースで、小さな部分だけが変更された場合や、 特定の変更を適用したい同時編集に役立つ。LWS サーバーは、[RFC7386]で定義されるJSON Merge Patch（application/merge-patch+json）を 最低限サポートしなければMUSTならない。

リソースメタデータの更新（リンクセット上のHTTP PUT / PATCH） リソースのメタデータは、rel="linkset"を持つLinkヘッダーを介して発見される、対応するリンクセットリソースを 変更することで更新される。 完全置換（PUT）: 完全なリンクセット文書を本文に含む、リンクセットリソースURIへのPUT要求は、 リソースのすべてのメタデータを置換する。 部分更新（PATCH）: リンクセットリソースURIへのPATCH要求は、特定のリンクを追加、削除、または 変更する。

メタデータの同時実行制御 リソースのメタデータは複数の行為者によって変更され得るため、同時上書きの防止は 重要である。データ完全性を確保するため、LWSサーバーおよびクライアントは、 リンクセットリソース上のすべての PUTおよびPATCH操作について、条件付き要求[RFC7232]を使用する楽観的同時実行制御を実装しなければMUSTならない。 サーバーの責任: サーバーは、リンクセットリソースに対するGETおよびHEAD要求への応答にEtagヘッダーを含めなければMUSTならない。 リンクセット上のPUTまたはPATCHが成功した場合、サーバーは変更されたリンクセットに対して新しい 一意のEtag値を生成し、それを応答のEtagヘッダーで返さなければMUSTならない。 クライアントの責任: リンクセットリソースを変更する場合、クライアントはそのリソースについて受け取った最新のEtagを含む If-Matchヘッダーを含めなければMUSTならない。 処理規則: If-Matchヘッダー値がリンクセットの現在のEtagと一致しない場合、サーバーは 412 Precondition Failedステータスコードで要求を拒否しなければMUSTならない。 リンクセットURIへのPUTまたはPATCH要求からIf-Matchヘッダーが欠けている場合、サーバーは 428 Precondition Requiredステータスコード[RFC6585]で要求を拒否しなければMUSTならない。 例（リンクセットを置換するPUT）: クライアントはまずリンクセットを取得し、そのETagを受け取る。

GET /alice/personalinfo.json.meta HTTP/1.1
Authorization: Bearer <token>
Accept: application/linkset+json
HTTP/1.1 200 OK
Content-Type: application/linkset+json
ETag: "meta-v1"
{
  "linkset": [
    {
      "anchor": "/alice/personalinfo.json",
      "describedby": [ { "href": "/schemas/personal-info.json" } ]
    }
  ]
}

クライアントは今、ライセンスを追加したい。新しい完全なリンクセット文書を構築し、If-Matchヘッダーを持つPUT 要求を送信する。

PUT /alice/personalinfo.json.meta HTTP/1.1
Authorization: Bearer <token>
Content-Type: application/linkset+json
If-Match: "meta-v1"
{
  "linkset": [
    {
      "anchor": "/alice/personalinfo.json",
      "describedby": [ { "href": "/schemas/personal-info.json" } ],
      "license": [ { "href": "https://creativecommons.org/licenses/by/4.0/" } ]
    }
  ]
}

成功した場合、サーバーは成功と新しいETagで応答する。

HTTP/1.1 204 No Content
ETag: "meta-v2"

更新規則の概要 リソースのコンテンツだけを変更したい場合 → リソース自体にPUT/PATCHする。 リソースのリンク（メタデータ）だけを変更したい場合 → リソースに関連付けられたリンクセットリソースにPUT/PATCHする。 コンテンツとリンクの両方を変更したい場合 → 適切な Linkヘッダーおよび'Prefer: set-linkset'を含めてリソース自体にPUT/PATCHする。両方を設定することは既定ではオフである。

リソースおよびその関連メタデータを恒久的に削除する。

• 入力: 対象識別子、任意の再帰フラグ（コンテナの場合）、および任意の同時実行制約。
• 振る舞い:
  • 非コンテナリソースについて、サーバーはコンテンツ、メタデータを削除し、 親コンテナのメンバーシップを更新する。
  • コンテナについて、再帰削除が 明示的に要求されサポートされていない限り、サーバーは通常コンテナが空であることを要求する。
• 結果: 削除の確認または失敗の通知。

リソースを削除する操作は、上記の抽象 操作で定義されるように、HTTP DELETEメソッドを使用して実装される。この節は、入力、振る舞い、および応答のHTTPバインディングを指定する。

DELETE要求は、削除するリソースまたはコンテナのURIを対象とする。クライアントは、 同時実行検査のためにETagを持つIf-Matchヘッダーを含めてもMAYよい。

削除と包含: リソースが削除される場合、サーバーはそれを 親コンテナのitems一覧から原子的に削除しなければMUSTならない。親コンテナの totalItems数は、それに応じて更新されるべきSHOULDであり、そのETagは 変更を反映するよう更新されなければMUSTならない。

非コンテナリソースについて、サーバーはリソースコンテンツ、その関連メタデータ（リンクセットリソース）、および親コンテナ内の包含参照を 削除する。

コンテナリソースについて、サーバーは既定で非再帰 削除を行う。コンテナが空でなく、再帰が要求されていない場合、サーバーは 409 Conflictで要求を拒否しなければMUSTならない。サーバーは、 削除されるコンテナ内のすべての包含リソースの再帰削除を サポートしてもMAYよい。クライアントは、 [RFC4918]で定義されるように、再帰削除を要求するために Depth: infinityヘッダーを使用しなければMUSTならない。

成功時、サーバーは204 No Contentで応答しなければMUSTならない。サーバーは、 [RFC9110]で定義される条件付き要求をサポートすべきSHOULDである。

クライアントが認可を欠く場合、サーバーは403 Forbidden（クライアントの 身元は既知だが権限が不足している場合）または401 Unauthorized（有効な 認証が提供されていない場合）を返さなければMUSTならない。リソースの存在を明らかにすることがセキュリティリスクをもたらす場合、 サーバーは代わりに404 Not Foundを返してもMAYよい。

例（非コンテナリソースをDELETEする）:

DELETE /alice/notes/shoppinglist.txt HTTP/1.1
Authorization: Bearer <token>
If-Match: "abc123456"

ETagが一致し、クライアントが認可されていると仮定すると、サーバーはリソース、そのメタデータを削除し、 親コンテナ/alice/notes/からそれを原子的に削除する:

HTTP/1.1 204 No Content

例（再帰なしで空でないコンテナをDELETEする）:

DELETE /alice/notes/ HTTP/1.1
Authorization: Bearer <token>

/alice/notes/がリソースを含むと仮定すると、サーバーは削除を拒否する:

HTTP/1.1 409 Conflict
Content-Type: text/plain

Cannot delete container /alice/notes/ - container is not empty.

例（サポートされる場合、再帰でコンテナをDELETEする）:

DELETE /alice/notes/ HTTP/1.1
Authorization: Bearer <token>
Depth: infinity

サーバーが再帰をサポートし、クライアントがすべての内容に対する権限を持つと仮定すると、サーバーは コンテナとその子孫を原子的に削除する:

HTTP/1.1 204 No Content

この表は、ページネーション、同時実行制御、クォータ制約、およびメタデータ統合などの 特定シナリオを組み込みながら、一貫性のために汎用LWS応答（第 8節から）をHTTPステータスコードおよびペイロードへマッピングする:

ストレージは通知をサポートしてもよい。通知をサポートするストレージは、そのストレージ記述 リソースのservice配列内で、typeがNotificationServiceに等しい サービスオブジェクトを通知しなければならない。

サービスオブジェクトは、その値がサブスクリプションエンドポイントのURIである serviceEndpointプロパティを含まなければならない。サービスオブジェクトは、 その値が文字列の配列であり、それぞれがサポートされるサブスクリプションタイプを識別する subscriptionTypeプロパティを含まなければならない。

サービスオブジェクトには追加のプロパティが存在してもよい。

{
  "@context": ["https://www.w3.org/ns/lws/v1"],
  "id": "https://storage.example/",
  "type": "Storage",
  "service": [{
    "type": "NotificationService",
    "serviceEndpoint": "https://notification.example/subscriptions",
    "subscriptionType": [
      "WebhookSubscription"
    ]
  }]
}

通知は、Notificationタイプを持つ JSON-LD文書として表現される。エンベロープは配信コンテキストに関するメタデータを保持し、 イベントを記述するActivity Streams 2.0 [ACTIVITYSTREAMS-CORE] [ACTIVITYSTREAMS-VOCABULARY] アクティビティを包含する。

{
  "@context": [
    "https://www.w3.org/ns/lws/v1",
    "https://www.w3.org/ns/activitystreams"
  ],
  "type": "Notification",
  "storage": "https://storage.example/",
  "activity": {
    "id": "ec4dcc48-6581-4232-81c9-584525a98693",
    "type": ["Delete"],
    "object": {
      "id": "https://storage.example/alice/notes/shopping.txt",
      "type": ["DataResource"]
    },
    "origin": "https://storage.example/alice/notes/",
    "published": "2026-03-26T10:30:00Z"
  }
}

{
  "@context": [
    "https://www.w3.org/ns/lws/v1",
    "https://www.w3.org/ns/activitystreams"
  ],
  "type": "Notification",
  "storage": "https://storage.example/",
  "activity": [
    {
      "id": "a1b2c3d4-5678-9abc-def0-1234567890ab",
      "type": ["Create"],
      "object": {
        "id": "https://storage.example/alice/notes/meeting.txt",
        "type": ["DataResource"]
      },
      "target": "https://storage.example/alice/notes/",
      "published": "2026-03-26T10:30:00Z"
    },
    {
      "id": "b2c3d4e5-6789-abcd-ef01-234567890abc",
      "type": ["Update"],
      "object": {
        "id": "https://storage.example/alice/profile",
        "type": ["DataResource"]
      },
      "published": "2026-03-26T10:30:01Z"
    }
  ]
}

通知を受信するため、サブスクライバーは、 NotificationServiceのserviceEndpointに 認証済みのPOST要求を送信することにより、サブスクリプションを 作成する。要求本体はapplication/lws+jsonメディアタイプに 適合しなければならない。

POST /subscriptions HTTP/2
Host: notification.example
Authorization: Bearer <access-token>
Content-Type: application/lws+json

{
  "@context": ["https://www.w3.org/ns/lws/v1"],
  "type": "WebhookSubscription",
  "topic": [
    "https://storage.example/alice/notes/",
    "https://storage.example/alice/profile"
  ],
  "inbox": "https://receiver.example/hooks/lws"
}

ストレージは、そのストレージ記述リソースで、 アクセス要求および アクセス許可のサポートを通知してもよい。 このようなサポートが通知される場合、アクセス要求のエンドポイントを記述するサービス オブジェクトは、文字列AccessRequestServiceに等しい typeを持たなければならず、アクセス許可のエンドポイントを記述する サービスオブジェクトは、文字列AccessGrantServiceに等しい typeを持たなければならない。サービス オブジェクトは、その値が、そのエンドポイントでサポートされるアクセスプロファイルを識別する1つ以上のURIの集合である conformsToプロパティを含むことが望ましい。 追加のプロパティを含めてもよい：

{
  "@context": [
    "https://www.w3.org/ns/cid/v1",
    "https://www.w3.org/ns/lws/v1"
  ],
  "id": "https://storage.example/",
  "type": "Storage",
  "service": [
    {
      "type": "StorageRoot",
      "serviceEndpoint": "https://storage.example/root/"
    },
    {
      "type": "AccessRequestService",
      "serviceEndpoint": "https://access.example/request/",
      "conformsTo": ["https://www.w3.org/ns/lws#AccessProfile"]
    },
    {
      "type": "AccessGrantService",
      "serviceEndpoint": "https://access.example/grant/",
      "conformsTo": ["https://www.w3.org/ns/lws#AccessProfile"]
    }
  ]
}

アクセス要求またはアクセス許可は、 アイデンティティおよびルーティングのためのプロパティと、要求または許可された操作を記述する accessオブジェクトを表現するデータオブジェクトである。ODRLの概念を使用して アクセス要求を記述するプロファイルについては、11.3 アクセスプロファイルで説明する。

次の例は、アクセス要求を示す。この例は、 11.4.1 JSON-LDシリアル化で定義されるJSON-LDシリアル化を使用して示されている。

{
  "@context": [
    "https://www.w3.org/ns/lws/v1"
  ],
  "type": ["AccessRequest"],
  "inbox": "https://id.example/agent/inbox/",
  "storage": "https://storage.example/",
  "access": [{
    "type": ["AccessPolicy"],
    "action": ["read", "create"],
    "assignee": "https://id.example/agent",
    "target": {
      "type": "StorageResource",
      "value": ["https://storage.example/root/projects/"]
    },
    "constraint": [
      {
        "leftOperand": "purpose",
        "operator": "eq",
        "rightOperand": "https://purpose.example/collaboration"
      },
      {
        "leftOperand": "dateTime",
        "operator": "lteq",
        "rightOperand": "2026-06-09T10:00:00Z"
      }
    ]
  }]
}

次の例は、アクセス許可を示す。この例は、 11.4.1 JSON-LDシリアル化で定義されるJSON-LDシリアル化を使用して示されている。

{
  "@context": [
    "https://www.w3.org/ns/lws/v1"
  ],
  "type": ["AccessGrant"],
  "storage": "https://storage.example/",
  "access": [{
    "type": ["AccessPolicy"],
    "action": ["read"],
    "assignee": "https://id.example/agent",
    "target": {
      "type": "StorageResource",
      "value": ["https://storage.example/root/projects/"]
    },
    "constraint": [
      {
        "leftOperand": "purpose",
        "operator": "eq",
        "rightOperand": "https://purpose.example/collaboration"
      },
      {
        "leftOperand": "dateTime",
        "operator": "lteq",
        "rightOperand": "2026-06-09T10:00:00Z"
      }
    ]
  }]
}

アクセス要求および アクセス許可には、他のプロパティが存在してもよい。

{
  "type": ["AccessGrant"]
}

{
  "storage": "https://storage.example/"
}

{
  "inbox": "https://id.example/agent/inbox/"
}

この仕様は、 ODRL情報モデルおよびODRL 語彙に基づき、次のURLで識別される アクセスプロファイルを定義する： https://www.w3.org/ns/lws#AccessProfile。

{
  "access": [{
    "type": ["AccessPolicy"]
  }]
}

{
  "access": [{
    "action": ["read", "create"]
  }]
}

{
  "access": [{
    "assignee": "https://id.example/agent"
  }]
}

{
  "access": [{
    "target": {
      "type": "StorageResource",
      "value": [
        "https://storage.example/root/2025",
        "https://storage.example/root/2026"
      ]
    }
  }]
}

{
  "access": [{
    "constraint": [
      {
        "leftOperand": "purpose",
        "operator": "isAnyOf",
        "rightOperand": [
          "https://purpose.example/collaboration",
          "https://purpose.example/research"
        ]
      }
    ]
  }]
}

{
  "access": [{
    "constraint": [
      {
        "leftOperand": "client",
        "operator": "eq",
        "rightOperand": "https://app.example/client-id"
      }
    ]
  }]
}

{
  "access": [{
    "constraint": [
      {
        "leftOperand": "format",
        "operator": "isAnyOf",
        "rightOperand": ["image/jpeg", "image/png"]
      }
    ]
  }]
}

Link: <https://www.w3.org/ns/lws#DataResource>; rel="type"
Link: <https://type.example/Playlist>; rel="type"

{
  "access": [{
    "constraint": [
      {
        "leftOperand": "type",
        "operator": "isAnyOf",
        "rightOperand": [
          "https://type.example/Playlist",
          "https://type.example/Song"
        ]
      }
    ]
  }]
}

{
  "access": [{
    "constraint": [
      {
        "leftOperand": "dateTime",
        "operator": "gteq",
        "rightOperand": "2026-03-09T12:00:00Z"
      },
      {
        "leftOperand": "dateTime",
        "operator": "lteq",
        "rightOperand": "2026-06-09T10:00:00Z"
      }
    ]
  }]
}

{
  "access": [{
    "action": ["read"],
    "assignee": "https://id.example/agent",
    "target": {
      "type": "StorageResource",
      "value": ["https://storage.example/root/projects/"]
    },
    "constraint": [
      {
        "leftOperand": "dateTime",
        "operator": "lteq",
        "rightOperand": "2026-06-09T10:00:00Z"
      },
      {
        "leftOperand": "client",
        "operator": "eq",
        "rightOperand": "https://app.example/client-id"
      }
    ]
  }]
}

この節で定義するデータモデルは、特定の シリアル化に依存しない。

{
  "@context": [
    "https://www.w3.org/ns/lws/v1"
  ]
}

アクセス要求およびアクセス許可の エンドポイントはLWSコンテナーであり、この仕様で定義される規則に 適合しなければならない。

これらのエンドポイントでは、最低限GETおよびPOST操作のサポートが必要である。 DELETE操作が推奨される。その他の操作をサポートしてもよい。

これらのエンドポイントは、要求および応答ペイロードの両方について、 11.4.1 JSON-LD シリアル化で定義されるJSON-LDシリアル化をサポートしなければならない。 サーバーは、追加のシリアル化をサポートしてもよい。

エージェントは、 アクセス要求エンドポイントに POST要求を送信することにより、アクセス要求を作成する。 ストレージ コントローラーは、アクセス許可エンドポイントに POST要求を送信することにより、アクセス許可を作成する。

成功したPOST操作は、Locationヘッダーを 新しいリソースのURLに設定して応答しなければならない。

通知は、エージェントおよびストレージ コントローラーに、 アクセス要求およびアクセス許可の変更について 通知するためのメカニズムを提供する。アクセス要求またはアクセス許可に inboxプロパティが存在する場合、サーバーは、割当先にイベントを通知するため、 そのエンドポイントに通知を配信することが望ましい。

通知のシリアル化は、LWS通知データモデルの要件に 適合しなければならない。

inboxエンドポイントに配信される通知は、通知配信について LWSプロトコルで定義される要件に適合しなければならない。

LWS ストレージ記述は、メディアタイプ application/lws+cid でシリアライズ可能でなければならない。 application/lws+cid メディアタイプは、LWS 語彙で拡張された W3C Controlled Identifier 文書 [CID-1.0] を特殊化した文書を識別する。

LWS コンテナー表現は、メディアタイプ application/lws+json に対応しなければならない。

LWS コンテナー表現は JSON-LD の規約を使用するが、LWS の制約および要件は、 特定のメディアタイプを使用する根拠となる。LWS コンテナーは JSON-LD の制限付きプロファイルとみなせるため、 実装は、メディアタイプ application/ld+json; profile="https://www.w3.org/ns/lws/v1" を application/lws+json と同等とみなすべきである。

GET /alice/photos/ HTTP/1.1
Authorization: Bearer <token>
Accept: application/lws+json

HTTP/1.1 200 OK
Content-Type: application/lws+json
ETag: "photos-page1-etag"
Link: </alice/photos/.meta>; rel="linkset"; type="application/linkset+json"
Link: </alice/>; rel="up"
Link: <https://www.w3.org/ns/lws#Container>; rel="type"
Link: </alice/photos/?page=1>; rel="first"
Link: </alice/photos/?page=3>; rel="last"
Link: </alice/photos/?page=2>; rel="next"

{
  "@context": "https://www.w3.org/ns/lws/v1",
  "id": "/alice/photos/",
  "type": "Container",
  "totalItems": 150,
  "items": [
    {
      "type": "DataResource",
      "id": "/alice/photos/vacation.jpg",
      "format": "image/jpeg",
      "size": 248392,
      "modified": "2025-11-20T10:30:00Z"
    },
    {
      "type": "DataResource",
      "id": "/alice/photos/portrait.png",
      "format": "image/png",
      "size": 102400,
      "modified": "2025-11-21T14:15:00Z"
    }
  ]
}

GET /alice/photos/?page=2 HTTP/1.1
Authorization: Bearer <token>
Accept: application/lws+json

HTTP/1.1 200 OK
Content-Type: application/lws+json
ETag: "photos-page2-etag"
Link: </alice/photos/.meta>; rel="linkset"; type="application/linkset+json"
Link: </alice/>; rel="up"
Link: <https://www.w3.org/ns/lws#Container>; rel="type"
Link: </alice/photos/?page=1>; rel="first"
Link: </alice/photos/?page=1>; rel="prev"
Link: </alice/photos/?page=3>; rel="next"
Link: </alice/photos/?page=3>; rel="last"

{
  "@context": "https://www.w3.org/ns/lws/v1",
  "id": "/alice/photos/",
  "type": "Container",
  "totalItems": 150,
  "items": [
    {
      "type": "DataResource",
      "id": "/alice/photos/sunset.jpg",
      "format": "image/jpeg",
      "size": 315000,
      "modified": "2025-11-22T09:00:00Z"
    }
  ]
}