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/metadata>; rel="storageDescription"
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/lws/v1",
  "id": "https://storage.example/",
  "type": "Storage",
  "service": [{
    "type": "StorageDescription",
    "serviceEndpoint": "https://storage.example/description"
  }]
}

{
  "@context": "https://www.w3.org/ns/lws/v1",
  "id": "https://storage.example/",
  "type": "Storage",
  "capability": [{
    "type": "https://feature.example/PatchSupport",
    "mediaType": {
      "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": "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"
  }, {
    "type": "StorageDescription",
    "serviceEndpoint": "https://storage.example/description"
  }]
}

Linked Web Storageは、リソースをコンテナに編成する。コンテナは、 メンバーと呼ばれる他のリソースへの参照を保持する特殊化されたリソースである。コンテナは、 ディレクトリまたはコレクションに類似した編成単位として機能し、クライアントがリソースをグループ化、発見、 およびナビゲートできるようにする。コンテナは、そのメンバーリソースへの参照を保持し、 それらは非コンテナリソースと追加のコンテナリソースの両方から構成されてもよく、それにより 階層的な構成が可能になる。通常、コンテナは、メンバーのメタデータまたは列挙を超える 最小限の固有コンテンツを保持し、その主な役割は下位リソースを集約し構造化することである。 ストレージシステムのルートはコンテナとして指定され、 上位の親を持たない最上位の編成単位として機能する。コンテナは、'ContainerPage'型を使用して メンバーシップ一覧のページネーションをサポートしなければMUSTならず、'first'、 'next'、'prev'、および'last'などのプロパティを用いる。表現は、特定のフレームおよび規範的コンテキストを伴う JSON-LDを使用しなければMUSTならず、任意で'Vary: Accept'ヘッダーを介して コンテンツネゴシエーションを広告してもよい。 ストレージは、ルートコンテナとして機能し、直接書き込みを可能にしてもMAYよい。

すべての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を割り当て、 クライアントヒント（例: Slugヘッダー）を組み込んでもMAYよいが、 クライアントはURI構造が包含を反映していると仮定すべきではSHOULD NOTない。

包含関係は、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",
      "mediaType": "text/plain",
      "size": 47,
      "modified": "2025-11-24T12:00:00Z"
    },
    {
      "type": ["DataResource", "http://example.org/customType"],
      "id": "/alice/notes/todo.json",
      "mediaType": "application/json",
      "size": 2048,
      "modified": "2025-11-24T13:00:00Z"
    }
  ]
}

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

メタデータモデル LWSにおけるすべてのメタデータは、リソース（リンクコンテキスト）から発生する型付きリンクの集合として表現される。 各リンクは次から構成される:

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

メタデータは、リソースとその表現を区別し、該当する場合には複数のメディア型を 可能にする。データリソースについて、メタデータには表現が含まれ、それぞれが mediaTypeおよび任意のsizeInBytesを持つ。コンテナおよびデータリソースについては、 その親コンテナリソースへのリンクを、そのリソースのメタデータの一部とみなす。

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

• 発見: リソースのリンクセットは、 rel="linkset"関係を持つLinkヘッダーを介して発見可能である。
• メディア型: リンクセットリソースはapplication/linkset+jsonとして 利用可能でなければMUSTならない。
• 完全性: 'linkset'リンクは、サーバー管理リソースを指さなければMUSTならない。 リンクセットへの更新は、一貫性を維持するために、関連するリソース操作と原子的でなければMUST ならない。

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

• ストレージ記述: サーバーは、関連する応答上で rel="storageDescription"を持つLinkヘッダーをサポートしなければMUSTならない。
• 包含: サーバーは、任意の 非ルートリソースについて、親コンテナを指す rel="up"を持つLinkヘッダーを含めなければMUSTならない。
• プリファレンス: クライアントは、特定の関係を含めるまたは省略するために、 URI https://www.w3.org/ns/lws#PreferLinkRelationsを持つPreferヘッダー[RFC7240]を使用してもMAYよい。

メタデータ型

変更可能性に関する考慮事項 中核メタデータはクライアントによって変更されてもMAYよい。相互運用性を確保するため、サーバーは 標準HTTPヘッダーを用いて自身の機能を広告しなければMUSTならない:

1. メソッド発見: サーバーは、Allowヘッダーを介してリンクセットリソース上のGETおよびPATCH 操作のサポートを広告しなければMUSTならない。

2. パッチ形式の発見: サーバーは、Accept-Patchヘッダーを介してJSON Merge Patch [RFC7386]のサポートを広告しなければMUSTならない: Accept-Patch: application/merge-patch+json.

3. 任意メソッド: サーバーはPUTまたは代替パッチ形式をサポートしてもMAYよい。 サポートする場合、それらはそれぞれAllowおよびAccept-Patch ヘッダーに含められなければMUSTならない。

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

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

• 部分更新（PATCH）: これはメタデータ管理の主要なメカニズムである。サーバーは、 application/merge-patch+jsonを使用するPATCHをサポートしなければMUSTならない。

• 置換（PUT）: Allowヘッダーで広告される場合、クライアントはリンクセット全体を置換してもMAY よい。サーバーがPUTをサポートしない場合、サーバーは405 Method Not Allowedで要求を拒否しなければMUST ならない。

• 制限: サーバーは、システムの完全性を維持するために、特定のリンク（ upまたはitemsなど）への変更を制限してもMAYよい。

• ライフサイクル: メタデータのライフサイクルは、記述されるリソースに結び付けられる。リソースの削除は、 その関連するリンクセットリソースメタデータの自動削除をもたらさなければMUSTならない。

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

入力:

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

振る舞い:

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

可能な応答:

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

新しいリソースは、対象コンテナURIへのPOSTを使用して作成され、サーバーが 最終的な識別子を割り当てる。クライアントはSlugヘッダーを介して名前を提案してもMAYよい。 クライアントは、[RFC8288]におけるWeb Linkingの構文に従って、 POST要求に1つ以上のLinkヘッダーを含めることで、新しいリソースの初期ユーザー管理メタデータを提供してもMAYよい。 サーバー管理メタデータは、作成時にサーバーによって自動的に生成されなければMUST ならず、クライアント提供リンクによって上書きされてはMUST NOTならない。

成功時、サーバーは201ステータスコードを、Locationヘッダー内の新しいURIとともに返さなければMUSTならない。 サーバーは、親コンテナ （rel="up"）へのリンク、および作成されたリソース専用のリンクセットリソースへのリンク （rel="linkset"; type="application/linkset+json"）を含む、主要なサーバー管理メタデータの Linkヘッダーを含めなければMUSTならない。追加リンクは、rel="type"（ https://www.w3.org/ns/lws#Containerまたは https://www.w3.org/ns/lws#DataResourceを示す）を含むべきSHOULDである。本文は空でもMAYよく、または リソースの最小表現を含んでもよい。すべてのメタデータ作成およびリンク付けは、一貫性を維持するために、 リソース作成と原子的でなければMUSTならない。

POST（コンテナURIへ） – サーバー割り当て名で作成: 既存のコンテナ内に新しいリソースを追加するにはPOSTを使用する。サーバーはリソースに識別子を割り当て、 任意でSlugヘッダーを介して提案される。サーバーは、命名規則または既存 リソースと競合しない場合、Slugヘッダーを尊重してもMAYよい。クライアントは、作成するリソースの型を次のように示す:

• コンテナを作成するには、クライアントは Container型を指すrel="type"を持つLinkヘッダーを含めなければMUSTならない: 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
Slug: shoppinglist.txt

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エラーステータスを返さなければMUSTならない。

コンテナの作成: 新しいコンテナを作成するには、クライアントはContainer型を示す Linkヘッダーを持つ、既存の親コンテナへのPOSTを使用する。 例:

POST /alice/ HTTP/1.1
Host: example.com
Authorization: Bearer <token>
Content-Length: 0
Slug: notes
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/に新しいコンテナを作成し、rel="type"を https://www.w3.org/ns/lws#Containerとして含むサーバー生成メタデータを伴う。

Create（HTTPバインディング）に関する追加注記:

• POSTは冪等ではない。繰り返すと重複が作成される可能性があるため、クライアントは意図しない再試行を避けるべきSHOULD であり、またはこれを防ぐために一意な識別子/検査を使用すべきである。
• メタデータ更新は原子的である。サーバーは、成功を返す前に、リンクセットリソースが作成され、必須の サーバー管理フィールドで設定されていることを保証しなければMUSTならない。
• 発見可能性のために、サーバーは、クライアントをハードコードされたURIなしで導くために、401応答に rel="storageDescription"を持つLinkヘッダーを含めるべきSHOULDである。

メタデータの管理および取得（作成に関連）: メタデータは主に読み取り操作を介して取得されるが、作成時に生成される。クライアントは、 作成後すぐに、新しいリソース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/ld+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",
      "mediaType": "text/plain",
      "size": 47,
      "modified": "2025-11-24T12:00:00Z"
    },
    {
      "type": ["DataResource", "http://example.org/customType"],
      "id": "/alice/notes/todo.json",
      "mediaType": "application/json",
      "size": 2048,
      "modified": "2025-11-24T13:00:00Z"
    }
  ]
}

この例では、/alice/notes/はコンテナである。応答は LWSコンテキストを持つJSON-LDを使用し、必須メタデータを持つメンバーを一覧化する。各項目は、 フラットなプロパティとしてtype、 id、mediaType、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ステータスコードおよびペイロードへマッピングする:

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

{
  "@context": [
    "https://www.w3.org/ns/lws/v1"
  ],
  "id": "https://storage.example/",
  "type": "Storage",
  "service": [
    {
      "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概念を用いてアクセス要求を記述する プロファイルは、10.3 アクセスプロファイルで記述される。

次の例は、アクセス要求を示す。この例は、 10.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/projects/"]
    },
    "constraint": [
      {
        "leftOperand": "purpose",
        "operator": "eq",
        "rightOperand": "https://purpose.example/collaboration"
      },
      {
        "leftOperand": "dateTime",
        "operator": "lteq",
        "rightOperand": "2026-06-09T10:00:00Z"
      }
    ]
  }]
}

次の例は、アクセス許可を示す。この例は、 10.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/projects/"]
    },
    "constraint": [
      {
        "leftOperand": "purpose",
        "operator": "eq",
        "rightOperand": "https://purpose.example/collaboration"
      },
      {
        "leftOperand": "dateTime",
        "operator": "lteq",
        "rightOperand": "2026-06-09T10:00:00Z"
      }
    ]
  }]
}

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

{
  "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/data/2025",
        "https://storage.example/data/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": "mediaType",
        "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/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コンテナであり、この仕様で定義される規則に適合しなければMUST ならない。

これらのエンドポイントは、少なくともGETおよびPOST操作のサポートを必要とする。DELETE操作は RECOMMENDEDである。他の操作がサポートされてもMAYよい。

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

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

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

通知は、エージェントおよびストレージ コントローラーに対して、 アクセス要求およびアクセス許可の変更を知らせるための メカニズムを提供する。アクセス要求またはアクセス許可に inboxプロパティが存在する場合、サーバーは 譲受人にイベントを知らせる通知をそのエンドポイントへ配信すべきSHOULDである。

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

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

LWSのコンテナ表現およびストレージ記述リソースは、メディア型 application/lws+jsonを使用しなければMUSTならない。

LWSコンテナ表現はJSON-LDの規約を使用するが、LWSに対する制約および要件は、 特定のメディア型の使用を正当化する。LWSコンテナはJSON-LDの制限されたプロファイルとみなせるため、 実装は application/ld+json; profile="https://www.w3.org/ns/lws/v1"メディア型を application/lws+jsonと等価なものとして扱うべきSHOULDである。

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: </alice/photos/.acl>; rel="acl"
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",
      "mediaType": "image/jpeg",
      "size": 248392,
      "modified": "2025-11-20T10:30:00Z"
    },
    {
      "type": "DataResource",
      "id": "/alice/photos/portrait.png",
      "mediaType": "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: </alice/photos/.acl>; rel="acl"
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",
      "mediaType": "image/jpeg",
      "size": 315000,
      "modified": "2025-11-22T09:00:00Z"
    }
  ]
}