연결된 웹 스토리지 프로토콜 1.0

LWS 프로토콜은 어떤 주체가 일부 리소스를 다음 대상에게 제공할 수 있는 표준 상호작용을 정의합니다: 에이전트.

• 제공 리소스 - (이용 가능한 리소스? 게시된 리소스?) (UCS에 정의되어 있지 않음) 서비스가 상호작용을 위해 노출하는 네트워크로 접근 가능한 엔터티로, 이 문서에 정의된 프로토콜을 사용하여 조회하거나 조작할 수 있습니다.
• 요청 에이전트 - (엔터티라는 UCS 용어) 엔터티로서 (예: 클라이언트, 사용자 또는 프로세스), 제공 가능한 리소스와 상호작용하기 위한 요청을 시작합니다.

리소스 관리자는 제공 리소스를 비공개로 유지하거나 누구나 이용할 수 있도록 공개하거나, 다음과 같은 제한된 집합에만 표시되도록 제한할 수 있습니다: 요청 에이전트.

• 인증 - 다음 대상의 신원을 검증하는 과정입니다: 에이전트, 요청을 실행하는 주체입니다.
• 인가 - 다음 대상의 권한을 결정하는 과정입니다: 에이전트, 특정 리소스에 접근하거나 다음 집합 중 하나를 수행할 권한이 있는지를 결정합니다: 작업.
• 리소스 관리자 - (제어자, 해당 명세: UCS) 에이전트로서, 다음에 대한 접근을 제어할 권한을 가집니다: 제공 리소스.

비규범적으로 표시된 절뿐만 아니라, 이 명세의 모든 작성 지침, 다이어그램, 예시 및 참고 사항도 비규범적입니다. 이 명세의 나머지 모든 내용은 규범적입니다.

키워드 MAY, MUST, MUST NOT, OPTIONAL, RECOMMENDED, REQUIRED, SHOULD 및 SHOULD NOT를 이 문서에서는 다음에 설명된 대로 해석합니다: BCP 14 [RFC2119] [RFC8174] 단, 여기에 표시된 것처럼 모두 대문자로 나타나는 경우에만 해당합니다.

LWS 서버는 HTTP 서버이며 [rfc9112], 다음을 준수합니다: 이 명세의 모든 관련 "MUST" 문장. 구체적으로, 다음 절의 관련 규범적 "MUST" 문장을 9. 작업에서 반드시 준수해야 합니다.

LWS 클라이언트는 HTTP 클라이언트이며 [rfc9112], 이 명세의 모든 관련 "MUST" 문장을 준수합니다. 구체적으로, 관련 규범적 "MUST" 문장을 이 문서의 9. 작업에서 반드시 준수해야 합니다.

다음 다이어그램은 플랫폼 독립적인 모델로, 구현을 안내합니다.

이 절에 설명된 데이터 모델은 모든 구체적인 직렬화에 대한 요구 사항을 개괄합니다: 인증 자격 증명의 직렬화입니다.

인증 자격 증명은 반드시 주체에 관한 변조를 감지할 수 있는 클레임을 포함해야 하며, 다음을 포함합니다:

• 주체 필수 — 최종 사용자의 식별자입니다. 이는 반드시 URI여야 합니다.
• 발급자 필수 — 다음을 발급한 엔터티의 식별자입니다: 인증 자격 증명. 이는 반드시 URI여야 합니다.
• 클라이언트 필수 — 클라이언트 애플리케이션의 식별자입니다. 이는 가급적 URI인 것이 좋습니다.
• 수신 대상 제한 권장 — 값의 목록으로, 가급적 인가 서버 식별자를 포함하는 것이 좋습니다.

다음의 유효성 검사에는 인증 자격 증명, 신뢰 관계가 필요하며, 이는 자격 증명의 검증자와 발급자 간의 관계입니다. 이 신뢰 관계는 허용됩니다, 수립하는 것이 대역 외 메커니즘을 통해서도 가능합니다. 신뢰를 수립하기 위한 추가 메커니즘은 검증자와 발급자 사이에서 사용되며, 특정 인증 스위트에 개괄되어 있습니다.

인증 자격 증명은 반드시 서명되어야 합니다. 권장되는 서명 방식은 비대칭 암호화를 사용하는 것입니다.

각 인증 스위트는 반드시 토큰 유형 URI와 연결되어야 합니다. 인증 스위트는 가급적 IANA "OAuth URI" 레지스트리에 정의된 URI를 사용하는 것이 좋습니다.

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 resource_metadata="https://storage.example/.well-known/oauth-protected-resource/storage_1/photos/img.jpg",
                error="invalid_token"

{
    "resource": "https://storage.example/storage_1/photos/img.jpg",
    "authorization_servers": ["https://authorization.example"]
}

{
    "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"],
    "subject_identifier_types_supported": [
        "did:web",
        "did:key",
        "https"]
}

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":300
}

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/storage_1",
  "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": "MoveResource",
    "appliesTo": ["DataResource", "Container"],
    "preservesIdentifier": true
  }],
  "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/json-patch+json", "application/merge-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"
  }]
}

Linked Web Storage는 리소스를 다음으로 구성합니다: 컨테이너. 컨테이너는 다른 리소스에 대한 참조를 보유하는 특수한 리소스로, 해당 리소스를 멤버라고 합니다. 컨테이너는 디렉터리나 컬렉션과 유사한 구성 단위로서, 클라이언트가 리소스를 그룹화하고 발견하며, 탐색할 수 있도록 합니다. 컨테이너는 멤버 리소스에 대한 참조를 유지하며, 여기에는 컨테이너가 아닌 리소스와 추가 컨테이너 리소스가 모두 포함될 수 있어 계층적 구성이 가능합니다. 일반적으로 컨테이너 자체의 고유 콘텐츠는 최소한이며, 메타데이터나 멤버의 열거를 제외하면 거의 없습니다. 주된 역할은 하위 리소스를 모으고 구조화하는 것입니다. 저장소 시스템의 루트는 컨테이너로 지정되며, 상위 부모가 없는 최상위 구성 단위로 기능합니다. 다음의 구조는 컨테이너 표현, 다음에 정의되어 있습니다: 8.1 컨테이너 표현. 미디어 유형과 페이지 나누기 요구 사항은 다음에 정의되어 있습니다: 12. LWS 미디어 유형. 저장소는 선택적으로 루트 컨테이너로 기능하여 직접 쓰기를 허용할 수 있습니다.

모든 LWS 저장소에는 저장소 루트가 있으며, 최상위 구성 단위로 기능합니다. 저장소 루트는 부모가 없으며 다음에 대한 진입점 역할을 합니다: 저장소 계층.

LWS의 리소스는 다음 중 하나로 분류됩니다:

• 컨테이너 — 다른 리소스를 포함하는 리소스입니다.
• 데이터 리소스 — 데이터를 담고 있는 리소스입니다. (예: 문서, 이미지 또는 구조화된 데이터 파일).

포함 관계는 리소스와 그 부모 컨테이너 간의 관계이며, rel="up" 링크 관계로 표현됩니다. 서버는 반드시 Link 헤더를 포함해야 하며, rel="up"이 부모 컨테이너를 가리켜야 합니다. 이는 모든 루트가 아닌 리소스에 대한 GET 및 HEAD 요청의 응답에 적용됩니다.

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

컨테이너의 멤버는 해당 표현에 나열되며, items 속성을 사용합니다. 서버가 이 목록을 관리하며, 클라이언트는 직접 수정할 수 없습니다. 멤버십 변경은 리소스 생성과 삭제의 부수 효과로 발생하며, 서버가 다음을 허용하는 경우에도 발생합니다: 리소스의 up 링크 수정. 이때 다음 간의 리소스 이동으로 발생합니다: 컨테이너, 이는 다음에 설명되어 있습니다: 9.6 컨테이너 간 리소스 이동.

서버는 반드시 다음을 유지해야 합니다: 포함 관계의 무결성을 항상 유지해야 합니다:

• 생성: 새 리소스가 다음에 생성되면, 컨테이너, 서버는 반드시 해당 리소스를 원자적으로 추가해야 합니다: 컨테이너의 items 목록에 추가합니다.
• 삭제: 리소스가 삭제되면 서버는 반드시 해당 리소스를 부모에서 원자적으로 제거해야 합니다: 컨테이너의 items 목록. 다음을 삭제하려면 컨테이너, 해당 컨테이너는 비어 있어야 합니다. 단, 재귀적 삭제를 명시적으로 요청한 경우는 예외입니다.
• 이동: 리소스의 up 링크가 변경되면 서버는 반드시 해당 리소스를 items 목록에서 원자적으로 제거해야 합니다. 이전 부모의 목록이며, 컨테이너의 목록입니다. 그리고 items 목록에 추가해야 합니다. 대상 컨테이너의 목록입니다. up 링크 변경 지원은 선택 사항이며, 그에 따른 요구 사항은 다음에 정의되어 있습니다: 9.6 리소스 이동 (컨테이너 간).
• 고아 리소스 없음: 모든 루트가 아닌 리소스에는 반드시 다음에서 도달할 수 있어야 합니다: 저장소 루트, 다음을 통해 도달합니다: 포함 관계 계층.
• 순환 없음: 컨테이너는 절대로 직접적으로나 간접적으로 자신을 포함해서는 안 됩니다.

리소스는 URI로 식별됩니다. 리소스의 URI는 다음에서의 위치와 독립적입니다: 포함 관계 계층. 서버는 리소스를 생성할 때 URI를 할당하며, 선택적으로 클라이언트의 힌트를 반영할 수 있습니다. 하지만 클라이언트는 가급적 URI 구조가 포함 관계를 반영한다고 가정하지 않는 것이 좋습니다.

포함 관계는 메타데이터를 통해 표현됩니다. (rel="up" 링크 및 items 속성, 다음에 있는 속성입니다: 컨테이너 표현), URI 경로 구조로 표현되지 않습니다. 이러한 분리는 서버에 URI 할당의 유연성을 제공하면서 명확하게 정의된 구성 모델을 유지할 수 있도록 합니다.

클라이언트가 다음에 대한 읽기 접근 권한을 가지면, 컨테이너, 해당 컨테이너 표현은 반드시 포함된 모든 리소스의 식별자를 포함해야 합니다. 해당 컨테이너에 있으며 클라이언트가 접근할 수 있는 리소스입니다. 또한 선택적으로 다음에 포함된 리소스의 식별자도 포함할 수 있습니다: 컨테이너, 클라이언트가 접근할 수 없는 리소스입니다.

클라이언트가 다음 목록을 읽을 수 있다고 해서, 컨테이너 목록, 포함된 리소스 자체에 접근할 수 있음을 의미하지는 않으며, 그 반대도 마찬가지입니다.

LWS 컨테이너 표현은 컨테이너와 그 내용을 설명합니다. 이 절은 필수 속성과 선택 속성을 정의하며, application/lws+json으로 제공되는 경우에 적용됩니다. 다른 RDF 미디어 유형의 표현은 콘텐츠 협상을 통해 요청할 수 있습니다.

{
  "@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"
    }
  ]
}

@prefix lws: <https://www.w3.org/ns/lws#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix schema: <http://schema.org/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<> a lws:Container ;
  lws:totalItems 2 ;
  lws:items <shoppinglist.txt>, <todo.json> .

<shoppinglist.txt> a lws:DataResource ;
  dcterms:format "text/plain" ;
  schema:size "47"^^xsd:long ;
  dcterms:modified "2025-11-24T12:00:00Z"^^xsd:dateTime .

<todo.json> a lws:DataResource, <http://example.org/customType> ;
  dcterms:format "application/json" ;
  schema:size "2048"^^xsd:long ;
  dcterms:modified "2025-11-24T13:00:00Z"^^xsd:dateTime .

<https://storage.example/alice/notes/> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/ns/lws#Container> .
<https://storage.example/alice/notes/> <https://www.w3.org/ns/lws#totalItems> "2"^^<http://www.w3.org/2001/XMLSchema#integer> .
<https://storage.example/alice/notes/> <https://www.w3.org/ns/lws#items> <https://storage.example/alice/notes/shoppinglist.txt> .
<https://storage.example/alice/notes/> <https://www.w3.org/ns/lws#items> <https://storage.example/alice/notes/todo.json> .
<https://storage.example/alice/notes/shoppinglist.txt> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/ns/lws#DataResource> .
<https://storage.example/alice/notes/shoppinglist.txt> <http://purl.org/dc/terms/format> "text/plain" .
<https://storage.example/alice/notes/shoppinglist.txt> <http://schema.org/size> "47"^^<http://www.w3.org/2001/XMLSchema#long> .
<https://storage.example/alice/notes/shoppinglist.txt> <http://purl.org/dc/terms/modified> "2025-11-24T12:00:00Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> .
<https://storage.example/alice/notes/todo.json> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/ns/lws#DataResource> .
<https://storage.example/alice/notes/todo.json> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://example.org/customType> .
<https://storage.example/alice/notes/todo.json> <http://purl.org/dc/terms/format> "application/json" .
<https://storage.example/alice/notes/todo.json> <http://schema.org/size> "2048"^^<http://www.w3.org/2001/XMLSchema#long> .
<https://storage.example/alice/notes/todo.json> <http://purl.org/dc/terms/modified> "2025-11-24T13:00:00Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> .

리소스 생성 작업은 새로운 제공 리소스를 기존 컨테이너에 추가합니다. 이 작업은 다음의 생성과 데이터 리소스, 하위 컨테이너의 생성을 모두 처리합니다.

입력:

• 대상 컨테이너: 다음의 식별자입니다: 컨테이너, 새 리소스를 생성할 위치입니다.
• 식별 힌트: 새 리소스의 식별자에 대한 선택적 제안입니다. 서버는 이 힌트를 사용할 수 있지만 반드시 사용할 필요는 없습니다.
• 콘텐츠: 새 리소스의 초기 콘텐츠와 유형입니다.

동작:

• 식별자 생성: 서버는 새 리소스의 최종 식별자(URI)를 결정합니다. 식별 힌트가 제공되면 서버는 이를 반영하려고 시도하면서 다음 내에서의 고유성과 유효성을 보장합니다: 컨테이너. 힌트가 제공되지 않으면, 서버가 고유 식별자를 생성합니다.
• 컨테이너 멤버십 갱신: 서버는 새 리소스를 원자적으로 대상의 멤버십 목록에 추가합니다: 컨테이너.
• 메타데이터 초기화: 서버는 새 리소스의 시스템 메타데이터를 초기화합니다. 리소스에 연결된 다음이 있으면, 메타데이터 리소스, 그것도 초기화합니다.

가능한 응답:

• 생성됨: 작업이 성공했습니다. 서버는 새로 생성한 리소스의 최종 식별자를 반환합니다.
• 대상을 찾을 수 없음: 지정된 대상 컨테이너가 존재하지 않습니다.
• 허용되지 않음: 클라이언트의 신원은 알려져 있지만, 이 대상에 리소스를 생성할 권한이 없습니다: 컨테이너.
• 알 수 없는 요청자: 서버가 클라이언트의 신원을 인식하지 못하며 인증을 요구합니다.
• 충돌: 생성된 식별자를 가진 리소스가 이미 존재하거나, 다른 상태 충돌이 있습니다.
• 알 수 없는 오류: 예상하지 못한 내부 오류가 발생했습니다.

새 리소스는 대상에 POST를 사용하여 생성합니다: 컨테이너 URI. 서버가 최종 식별자를 할당합니다. 클라이언트는 새 리소스의 초기 사용자 관리 메타데이터를 선택적으로 제공할 수 있으며, POST 요청에 하나 이상의 Link 헤더를 포함하여 다음의 구문을 따릅니다: 웹 링크, 다음에 정의되어 있습니다 [RFC8288]. 서버 관리 메타데이터는 반드시 생성 시 서버가 자동으로 생성해야 하며, 절대로 클라이언트가 제공한 링크로 덮어써서는 안 됩니다.

성공하면 서버는 반드시 201 상태 코드를 반환하고, 새 URI를 Location 헤더에 포함해야 합니다. 서버는 반드시 Link 헤더를 포함해야 하며, 주요 서버 관리 메타데이터에 대한 헤더로, 부모를 가리키는 링크를 포함합니다: 컨테이너 (rel="up"). 생성된 리소스 전용의 다음을 가리키는 링크도 포함합니다: 링크 집합 리소스 (rel="linkset"; type="application/linkset+json"). 추가 링크는 가급적 rel="type"을 포함하는 것이 좋습니다(다음을 나타냅니다: https://www.w3.org/ns/lws#Container 또는 https://www.w3.org/ns/lws#DataResource). 본문은 선택적으로 비어 있거나 리소스의 최소 표현을 포함할 수 있습니다. 모든 메타데이터 생성과 연결은 반드시 리소스 생성과 원자적으로 수행되어 일관성을 유지해야 합니다.

POST(컨테이너 URI 대상) – 서버가 할당한 이름으로 생성: POST를 사용하여 기존의 다음 내부에 새 리소스를 추가합니다: 컨테이너. 서버가 식별자를 리소스에 할당합니다. 클라이언트는 생성할 리소스의 유형을 다음과 같이 나타냅니다:

• 다음을 생성하려면, 컨테이너, 클라이언트는 반드시 rel="type"이 있는 Link 헤더를 포함해야 하며, Container 유형을 가리켜야 합니다: 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

우유
달걀
빵
버터
사과
오렌지 주스

이 예시에서 클라이언트는 다음에 POST 요청을 보냅니다: 컨테이너 /alice/notes/. text/plain 콘텐츠(식료품 목록)를 제공합니다. /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

예제(존재하지 않는 컨테이너에 POST):

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

test

만약 /alice/notes/ 가 존재하지 않으면 서버는 대상을 찾을 수 없음 결과를 보고한다:

HTTP/1.1 404 Not Found

참고: 리소스 생성 연산은 하나의 기존 컨테이너에 리소스를 추가한다. 포함 관계 는 URI 경로 구조가 아니라 메타데이터로 표현되므로( 7. 논리적 리소스 구성) 이 명세는 한 번의 연산으로 여러 수준의 컨테이너 를 생성하는 것을 정의하지 않는다. 클라이언트는 각 컨테이너 를 개별 리소스 생성 연산으로 생성한다.

생성: 컨테이너: 새로운 컨테이너를 생성하려면 클라이언트는 기존 부모에 POST를 보냅니다: 컨테이너, Link 헤더로 Container 유형을 나타냅니다. 예를 들면 다음과 같습니다:

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/에 생성하며, 서버가 생성한 메타데이터에는 rel="type"의 값으로 https://www.w3.org/ns/lws#Container가 포함됩니다.

생성에 대한 추가 참고 사항(HTTP 바인딩):

• POST는 멱등적이지 않습니다. 반복하면 중복이 생성될 수 있습니다. 클라이언트는 가급적 의도하지 않은 재시도를 피하거나 고유 식별자 또는 검사를 사용하여 이를 방지하는 것이 좋습니다.
• 메타데이터 갱신은 원자적입니다. 서버는 반드시 다음을 보장해야 합니다: 링크 집합 리소스가 생성되고 필수 서버 관리 필드가 채워진 후에 성공을 반환해야 합니다.
• 발견 가능성을 위해 서버는 가급적 다음이 있는 Link 헤더를 포함하는 것이 좋습니다: rel="https://www.w3.org/ns/lws#storage", 401 응답에 포함하여 하드코딩된 URI 없이 클라이언트를 안내합니다.

메타데이터 관리 및 조회(생성 관련): 메타데이터는 주로 읽기 작업을 통해 조회하지만, 생성 중에 만들어집니다. 클라이언트는 생성 직후 새 리소스 URI에 GET 또는 HEAD를 사용하여 이를 조회할 수 있습니다. 클라이언트는 Prefer 헤더를 사용하여 특정 메타데이터 링크(관계 유형을 통해) 및 속성의 포함을 요청할 수 있습니다.

기존 리소스의 표현 또는 다음의 목록을 조회합니다: 컨테이너.

• 입력: 대상 식별자와 선택적 매개변수입니다.
• 동작:
  • 컨테이너가 아닌 리소스의 경우, 서버는 리소스 콘텐츠를 반환합니다.
  • 다음의 경우, 컨테이너, 서버는 멤버 리소스의 목록을 반환하며, 리소스는 선택적으로 다음을 기준으로 필터링할 수 있습니다: 인가. 목록에는 각 멤버의 핵심 메타데이터를 포함해야 합니다.
• 결과: 요청된 표현 또는 실패 알림입니다.

리소스 읽기 작업은 HTTP GET 요청으로 리소스 표현을 요청합니다(헤더만 요청하려면 HEAD를 사용합니다). 동작은 대상 URL이 다음인지에 따라 다릅니다: 컨테이너 또는 컨테이너가 아닌 리소스(데이터 리소스). 서버는 반드시 메타데이터를 통해 리소스 유형을 구분해야 합니다. 모든 응답은 반드시 8.1절에 정의된 메타데이터와 통합되어야 하며, 다음과 같은 주요 관계의 Link 헤더를 포함합니다: rel="linkset", rel="up" 및 rel="type". 서버는 반드시 읽기 중에 리소스 상태와 메타데이터 간의 원자성을 보장해야 합니다.

GET(컨테이너가 아닌 리소스) – 리소스 콘텐츠 조회: 전체 콘텐츠를 얻으려면 리소스 URI에 GET을 보냅니다(인가된 경우). 200 OK로 응답하며, 본문에는 데이터를 포함하고 Content-Type은 저장된 미디어 유형과 일치해야 합니다. 서버는 반드시 다음에 따른 범위 요청을 지원해야 하며, [RFC7233], 부분 조회를 지원합니다. 응답은 반드시 다음에 정의된 ETag 헤더를 포함해야 합니다: [RFC9110].

예시(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"

우유
치즈
빵
과카몰레
탄산음료
초콜릿 바
해시
달걀

서버는 텍스트 콘텐츠를 반환했습니다(Content-Length에 표시된 대로 총 34바이트). 콘텐츠는 파일에 저장된 데이터와 정확히 같습니다. ETag: "abc123456"은 검증자로, 캐싱과 조건부 요청에 사용됩니다. 응답은 메타데이터 발견을 위한 Link 헤더를 포함하며, up 및 type과 같은 필수 필드를 포함합니다.

GET(컨테이너 리소스) – 목록 조회: 컨테이너의 내용: 대상 URI가 다음에 해당하면, 컨테이너(메타데이터 유형으로 결정), GET 요청은 다음의 목록을 반환합니다: 컨테이너의 멤버. 다음을 포함하는 응답은 Content-Type: application/lws+json, 컨테이너 표현이며, 다음에 정의되어 있습니다: 컨테이너 표현 절. 이 표현의 목록에는 각 멤버의 메타데이터가 포함됩니다: 리소스 식별자(필수), 유형(필수), 미디어 유형 (DataResources의 경우 필수), 크기(권장) 및 수정 타임스탬프(권장).

예시(GET으로 컨테이너 조회): 다음이 존재하고, 컨테이너, 클라이언트에게 접근 권한이 있다고 가정합니다. 탭은 동일한 요청을 서로 다른 미디어 유형으로 보여줍니다. 다음을 참조하세요: 12.1.2 콘텐츠 협상.

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"
    }
  ]
}

GET /alice/notes/ HTTP/1.1
Authorization: Bearer <token>
Accept: text/turtle; profile="https://www.w3.org/ns/lws/v1"

HTTP/1.1 200 OK
Content-Type: text/turtle; profile="https://www.w3.org/ns/lws/v1"
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"

@prefix lws: <https://www.w3.org/ns/lws#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix schema: <http://schema.org/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<> a lws:Container ;
  lws:totalItems 2 ;
  lws:items <shoppinglist.txt>, <todo.json> .

<shoppinglist.txt> a lws:DataResource ;
  dcterms:format "text/plain" ;
  schema:size "47"^^xsd:long ;
  dcterms:modified "2025-11-24T12:00:00Z"^^xsd:dateTime .

<todo.json> a lws:DataResource, <http://example.org/customType> ;
  dcterms:format "application/json" ;
  schema:size "2048"^^xsd:long ;
  dcterms:modified "2025-11-24T13:00:00Z"^^xsd:dateTime .

이 예시에서 /alice/notes/는 컨테이너입니다. 응답은 JSON-LD와 LWS 맥락을 사용하여 필수 메타데이터와 함께 멤버를 나열합니다. 각 항목에는 type, id, format, size 및 modified 타임스탬프가 평면 속성으로 포함됩니다.

모든 경우에 서버는 반드시 다음 메타데이터를 응답 헤더에 포함해야 합니다: 다음에 정의된 ETag 헤더, [RFC9110], 그리고 Link 헤더, rel="linkset", rel="up" 및 rel="type"이 있으며, 다음임을 나타냅니다: 컨테이너.

HEAD(모든 리소스 또는 컨테이너) – 헤더/메타데이터만: LWS 서버는 반드시 HEAD를 지원해야 합니다 [RFC9110]. 다음 모두에 적용됩니다: 컨테이너 및 컨테이너가 아닌 리소스. GET과 동일한 헤더를 반환하며, (Content-Type, 메타데이터용 Link 포함) 본문은 반환하지 않습니다. 이를 통해 콘텐츠를 전송하지 않고 메타데이터를 조회할 수 있습니다.

캐싱 및 조건부 요청: LWS는 HTTP 캐싱 의미론을 활용합니다. 서버는 가급적 다음에 정의된 조건부 요청을 지원하는 것이 좋습니다: [RFC9110], 엔터티 태그(ETags) 및 날짜 기반 검증자와 같은 메커니즘을 포함합니다(예: If-Modified-Since 헤더). 리소스 또는 컨테이너 목록이 변경되지 않았다면 304 Not Modified로 응답하여 불필요한 전송을 피합니다.

발견 가능성 및 인가: 발견 가능성을 높이기 위해, 401 Unauthorized 응답에는 WWW-Authenticate 헤더와 resource_metadata 매개변수가 포함되며, 이는 다음에 설명되어 있습니다: 인가 서버 발견. 이를 통해 클라이언트는 하드코딩된 URI 없이 인가 서버를 찾을 수 있습니다.

전체 교체 또는 부분 패치를 통해 기존 [제공 리소스]의 상태를 수정합니다.

• 입력: 대상 식별자, 새 콘텐츠 및 선택적 동시성 제약 조건입니다.
• 동작: 서버는 변경 사항을 원자적으로 적용합니다. 동시성 제약 조건이 제공되면, 요청자가 마지막으로 읽은 이후 리소스가 수정된 경우 갱신이 거부됩니다.
• 결과: 갱신 확인 또는 충돌 알림입니다.

리소스 갱신은 기존의 다음 콘텐츠를 수정합니다: 제공 리소스. PUT 요청(전체 리소스 교체) 또는 PATCH 요청( 부분 수정 적용)을 사용합니다. 클라이언트는 이러한 작업을 수행하려면 리소스 URL에 대한 쓰기 접근 권한을 가져야 합니다. 참고: 이 절은 리소스의 주요 콘텐츠 갱신을 설명합니다. 메타데이터를 갱신하려면 다음 절을 참조하세요: 9.3.2. LWS 서버는 반드시 리소스 URI에 대한 PUT 및 PATCH 요청을 리소스 콘텐츠만 수정하는 것으로 처리해야 하며, 기본적으로 연결된 다음에는 영향을 주지 않습니다: 링크 집합 리소스. 선택적으로 콘텐츠와 메타데이터를 하나의 원자적 작업으로 모두 갱신하려면, 클라이언트는 Link를 선택적으로 리소스 URI에 대한 PUT/PATCH 요청의 헤더에 포함하고 선호 사항을 지정할 수 있습니다: 'Prefer: set-linkset'(다음에 정의되어 있습니다: [RFC7240]). 이 경우 서버는 반드시 제공된 Link 헤더를 교체로 해석하거나, (PUT의 경우) 링크 집합에 대한 부분 갱신으로 해석해야 하며(PATCH의 경우), 콘텐츠 변경도 함께 적용합니다. 이 동작은 서버에 선택 사항이지만, 지원한다면 반드시 Prefer 헤더를 통해 명시적으로 호출해야 하며, 의도하지 않은 메타데이터 덮어쓰기를 방지하기 위한 것입니다. 결합 갱신을 지원하지 않는 서버는 반드시 해당 선호 사항을 무시하거나 501 Not Implemented로 응답해야 합니다.

PUT(전체 리소스 교체) – 리소스 URI에 PUT을 보내며, 새로운 전체 콘텐츠를 본문에 포함하고 일치하는 Content-Type을 사용합니다(일반적으로 기존 유형과 일치). PUT은 기존 리소스에 대해 멱등적입니다. 클라이언트는 가급적 다음에 정의된 조건부 요청을 사용하는 것이 좋습니다: [RFC9110], 동시에 발생한 변경 사항을 덮어쓰지 않기 위한 것입니다.

예시(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"
}

이 예시에서 클라이언트는 다음 위치의 기존 JSON 리소스를 갱신합니다: /alice/personalinfo.json. 엔터티 태그가 있는 If-Match 헤더를 포함하며, (ETag) 이전 GET 또는 HEAD 요청에서 받은 태그입니다. 서버는 이 태그를 현재 엔터티 태그(ETag)와 비교합니다. 일치하면 콘텐츠를 제공된 JSON으로 교체합니다. 일치하지 않으면 서버는 갱신을 거부합니다(그동안 다른 사람이 리소스를 변경했기 때문입니다). 성공 응답: 갱신이 성공하면 서버는 200 OK로 응답하고 갱신된 표현 또는 확인 정보(새 콘텐츠나 그 일부 등)를 포함할 수 있습니다. 또는 서버는 204 No Content로 응답하여 본문 없이 성공을 나타낼 수 있습니다. (추가 정보를 전달할 필요가 없을 때 특히 일반적입니다). 예를 들면 다음과 같습니다:

HTTP/1.1 204 No Content

• 오류 응답: If-Match 사전 조건이 일치하지 않으면 (동시 수정), 서버는 412 Precondition Failed로 응답합니다. 리소스가 존재하지 않으면 갱신 목적의 PUT은 404 Not Found를 발생시킵니다. 클라이언트가 인가되지 않았으면 403 Forbidden(유효한 자격 증명이 제공되지 않았으면 401 Unauthorized)입니다. 요청 페이로드가 유효하지 않으면 400 Bad Request입니다.

PATCH(부분 갱신) – HTTP PATCH 메서드는 [RFC5789] 클라이언트가 새로운 전체 콘텐츠를 보내는 대신 리소스의 부분 수정을 지정할 수 있도록 합니다. 큰 리소스에서 작은 부분만 변경되어 전체 콘텐츠를 보내는 것이 비효율적인 경우나 특정 변경 사항을 적용하려는 동시 편집에 유용합니다. LWS 서버는 반드시 최소한 JSON Patch를 지원해야 합니다. (application/json-patch+json) 다음에 정의되어 있습니다: [RFC6902].

리소스 메타데이터 갱신(링크 집합에 대한 HTTP PUT / PATCH) 리소스의 메타데이터는 해당하는 다음을 수정하여 갱신합니다: 링크 집합 리소스, rel="linkset"이 있는 Link 헤더를 통해 발견합니다. 전체 교체(PUT): 다음에 PUT 요청을 보내며, 링크 집합 리소스 URI, 완전한 링크 집합 문서를 본문에 포함하여 리소스의 모든 메타데이터를 교체합니다. 부분 갱신(PATCH): 다음에 PATCH 요청을 보내며, 링크 집합 리소스 URI, 특정 링크를 추가하거나 제거하거나 수정합니다.

메타데이터에 대한 조건부 요청 여러 주체가 리소스의 메타데이터를 수정할 수 있으므로, 동시에 발생하는 덮어쓰기를 방지하는 것이 중요합니다. 서버와 클라이언트는 가급적 다음에 정의된 조건부 요청을 사용하는 것이 좋습니다: [RFC9110], 다음에 대한 PUT 및 PATCH 작업에 사용합니다: 링크 집합 리소스. 서버가 사전 조건을 충족하지 않는 조건부 요청을 받으면, 반드시 다음으로 요청을 거부해야 합니다: 412 Precondition Failed 상태 코드. 예시(PUT으로 링크 집합 교체): 클라이언트가 먼저 링크 집합을 가져옵니다.

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
{
  "linkset": [
    {
      "anchor": "/alice/personalinfo.json",
      "describedby": [ { "href": "/schemas/personal-info.json" } ]
    }
  ]
}

클라이언트는 이제 라이선스를 추가하려고 합니다. 새롭고 완전한 링크 집합 문서를 구성하여 PUT 요청을 보냅니다.

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

성공하면 서버는 성공 응답을 보냅니다.

HTTP/1.1 204 No Content

갱신 규칙 요약 리소스의 콘텐츠만 변경하려면 → 리소스 자체에 PUT/PATCH를 보냅니다. 리소스의 링크(메타데이터)만 변경하려면 → 리소스에 연결된 다음에 PUT/PATCH를 보냅니다: 링크 집합 리소스. 콘텐츠와 링크를 모두 변경하려면 → 리소스 자체에 PUT/PATCH를 보내며, 적절한 Link 헤더와 'Prefer: set-linkset'을 모두 포함합니다. 둘 다 설정하는 동작은 기본적으로 비활성화되어 있습니다.

리소스와 연결된 메타데이터를 영구적으로 제거합니다.

• 입력: 대상 식별자, 선택적 재귀 플래그(다음에 적용: 컨테이너) 및 선택적 동시성 제약 조건입니다.
• 동작:
  • 컨테이너가 아닌 리소스의 경우, 서버는 콘텐츠와 메타데이터를 제거하고 부모의 컨테이너 멤버십을 갱신합니다.
  • 다음의 경우, 컨테이너, 서버는 일반적으로 다음이 컨테이너 비어 있어야 한다고 요구합니다. 단, 재귀적 삭제가 명시적으로 요청되고 지원되는 경우는 예외입니다.
• 결과: 제거 확인 또는 실패 알림입니다.

리소스 삭제 작업은 위의 추상 작업에 정의된 대로 HTTP DELETE 메서드를 사용하여 구현합니다. 이 절은 입력, 동작 및 응답의 HTTP 바인딩을 명시합니다.

DELETE 요청은 제거할 리소스 또는 다음의 URI를 대상으로 합니다: 컨테이너. 클라이언트는 선택적으로 ETag가 있는 If-Match 헤더를 포함하여 동시성 검사를 수행할 수 있습니다.

삭제 및 포함 관계: 리소스가 삭제되면 서버는 반드시 해당 리소스를 원자적으로 제거해야 합니다. 부모 컨테이너의 items 목록에서 제거합니다. 부모 컨테이너의 totalItems 개수는 가급적 그에 맞게 갱신하는 것이 좋습니다.

컨테이너가 아닌 리소스의 경우, 서버는 리소스 콘텐츠와 연결된 메타데이터(링크 집합 리소스) 및 포함 관계 참조를 부모에서 제거합니다: 컨테이너.

다음의 경우, 컨테이너 리소스, 서버는 기본적으로 비재귀적 삭제를 수행합니다. 다음이 컨테이너 비어 있지 않고 재귀가 요청되지 않았다면 서버는 반드시 409 Conflict로 요청을 거부해야 합니다. 서버는 선택적으로 다음 내부의 모든 리소스에 대한 재귀적 삭제를 지원할 수 있습니다: 컨테이너, 삭제 대상 컨테이너입니다. 클라이언트는 반드시 Depth: infinity 헤더를 사용하여 재귀적 삭제를 요청해야 하며, 이는 다음에 정의되어 있습니다: [RFC4918].

성공하면 서버는 반드시 204 No Content로 응답해야 합니다. 서버는 가급적 다음에 정의된 조건부 요청을 지원하는 것이 좋습니다: [RFC9110].

클라이언트에게 인가가 없으면 서버는 반드시 403 Forbidden을 반환해야 합니다( 클라이언트의 신원은 알려져 있지만 권한이 부족한 경우). 또는 401 Unauthorized를 반환해야 합니다(유효한 인증이 제공되지 않은 경우). 리소스의 존재를 공개하는 것이 보안 위험을 초래하면, 서버는 선택적으로 대신 404 Not Found를 반환할 수 있습니다.

예시(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

삭제할 수 없습니다: 컨테이너 /alice/notes/ - 컨테이너가 비어 있지 않습니다.

예시(지원되는 경우, 재귀를 사용하여 DELETE로 컨테이너 삭제):

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

서버가 재귀를 지원하고 클라이언트에게 모든 콘텐츠에 대한 권한이 있다고 가정하면, 서버는 컨테이너와 하위 항목을 원자적으로 삭제합니다:

HTTP/1.1 204 No Content

이 명세는 다음을 이동하기 위한 전용 HTTP 메서드를 정의하지 않습니다: 제공 리소스, 한 컨테이너에서 다른 컨테이너로 이동하는 것으로, MOVE 메서드와 다릅니다. WebDAV가 정의하는 메서드입니다 [RFC4918]. 대신 이동은 다음의 갱신으로 표현합니다: 포함 관계 메타데이터, 해당 리소스의 메타데이터입니다. 클라이언트는 리소스의 다음에서 up 링크를 변경합니다: 링크 집합 리소스, 목적지를 가리키도록 변경하며, 목적지는 컨테이너입니다. 다음을 사용합니다: 갱신 리소스 작업. 서버는 해당 변경으로부터 실제 이동을 도출합니다.

서버 지원: up 링크는 서버가 관리하며, 서버는 클라이언트가 이를 수정하도록 허용할 의무가 없습니다. 이는 다음에 설명되어 있습니다: 9.1 리소스 메타데이터. 클라이언트가 리소스의 up 링크를 수정하도록 허용하여, 그에 따라 다음 간 리소스 이동을 허용하는 서버는, 컨테이너, 반드시 다음을 설명해야 합니다: MoveResource 기능, 다음에 설명합니다: 저장소 설명. 이는 다음에 설명되어 있으며, 6.1.3 저장소 기능, 또한 반드시 이 절의 요구 사항을 구현해야 합니다. 허용하지 않는 서버는 반드시 409 Conflict와 같은 적절한 4xx 상태 코드로 요청을 거부해야 하며, 절대로 안 됩니다, MoveResource 기능을 설명해서는 안 됩니다.

이동 요청: 클라이언트는 리소스의 다음에 부분 갱신을 적용하여 리소스를 이동합니다: 링크 집합 리소스, up 링크의 대상을 목적지의 식별자로 교체하며, 목적지는 컨테이너입니다. 다음에서 요구하는 대로, 9.1 리소스 메타데이터, 서버는 반드시 application/json-patch+json을 지원해야 합니다 [RFC6902]. 이 갱신에 대한 지원입니다. 다음의 모든 수정과 마찬가지로, 링크 집합 리소스, 클라이언트는 가급적 현재 ETag를 담은 If-Match 헤더 필드를 포함하여 요청을 조건부로 만드는 것이 좋습니다. 해당 ETag의 대상은 링크 집합 리소스이며, 이는 다음에 설명되어 있습니다: 9.4 리소스 갱신. 서버는 선택적으로 조건부 요청을 요구하고 무조건부 요청을 428 Precondition Required로 거부할 수 있습니다.

목적지는 반드시 기존의 컨테이너여야 합니다. 서버는 반드시 up 링크의 대상을 다음 이외의 것으로 설정하려는 패치를 거부해야 합니다: 기존의 컨테이너. 409 Conflict와 같은 적절한 4xx 상태 코드로 거부합니다. 서버는 마찬가지로 반드시 리소스에 up 링크가 남지 않게 하는 패치를 거부해야 합니다. 모든 루트가 아닌 리소스에는 다음에서 도달할 수 있어야 하기 때문입니다: 저장소 루트.

이 명세는 목적지를 다음으로 제한하지 않습니다: 저장소, 이동할 리소스를 보유한 저장소입니다. 그러나 서버는 리소스를 다음으로 이동하는 것을 지원할 의무가 없습니다: 컨테이너, 다른 저장소에 있는 컨테이너이며, 선택적으로 이러한 패치를 적절한 4xx 상태 코드로 거부할 수 있습니다. 예를 들면 409 Conflict입니다. 이러한 패치를 수락하는 서버에는 이 절의 다른 요구 사항도 계속 적용되며, 변경을 원자적으로 적용해야 한다는 요구 사항도 포함됩니다.

다음에 미치는 영향: 포함 관계: 갱신에 성공하면 서버는 반드시 해당 리소스를 원자적으로 제거해야 합니다. items 목록에서 제거하며, 이전 부모의 목록입니다: 컨테이너. 그리고 다음에 추가해야 합니다: items 목록, 목적지의 목록입니다: 컨테이너. totalItems 개수는 두 대상 모두에서, 컨테이너, 가급적 그에 맞게 갱신하는 것이 좋으며, 두 대상의 ETag는 컨테이너, 반드시 갱신하여 변경을 반영해야 합니다.

이동한 리소스의 콘텐츠와 사용자 정의 메타데이터는 이동의 영향을 받지 않습니다. 서버는 반드시 다음의 링크를 보존해야 합니다: 링크 집합 리소스, 클라이언트가 수정할 권한이 없는 링크이며, linkset과 같은 서버 관리 링크 및 type을 포함합니다. 보조 리소스의 수명이 이동한 리소스에 종속되어 있다면, 이동 후에도 계속 해당 리소스에 종속됩니다.

서버는 반드시 다음의 무결성을 위반하는 갱신을 거부해야 합니다: 포함 관계, 해당 무결성의 요구 사항은 다음에 있습니다: 7. 논리적 리소스 구성. 409 Conflict와 같은 적절한 4xx 상태 코드로 거부합니다. 특히 컨테이너는 절대로 자기 자신 내부로 이동하거나 자신의 하위 항목 내부로 이동해서는 안 됩니다. 다음에 순환이 생기기 때문입니다: 포함 관계 계층.

이동한 리소스의 식별 정보: 리소스의 URI는 다음에서의 위치와 독립적이며, 포함 관계 계층, 이는 다음에 설명되어 있습니다: 7. 논리적 리소스 구성. 따라서 서버는 가급적 보존하는 것이 좋습니다. 이동한 리소스의 식별자를 보존하여 기존 링크가 계속 유효하도록 하며, 가급적 그 여부를 preservesIdentifier로 선언하는 것이 좋습니다. MoveResource 기능의 속성입니다. 해당 속성이 없으면 클라이언트는 절대로 식별자가 보존된다고 가정해서는 안 됩니다.

이동한 리소스의 식별자를 보존하지 않는 서버는 반드시 응답해야 합니다. 200 OK와 함께 갱신된 다음의 표현을 반환합니다: 링크 집합 리소스, 그 anchor는 리소스의 새 식별자여야 하며, 반드시 다음을 포함해야 합니다: Content-Location 헤더 필드, 다음의 새 식별자를 담는 필드입니다: 링크 집합 리소스 자체. 이러한 서버는 가급적 이전 식별자에 대한 후속 요청에 응답하는 것이 좋습니다. 리소스 및 해당 보조 리소스의 이전 식별자에 대해 301 Moved Permanently로 응답하며, 새 식별자를 가리키는 Location 헤더 필드를 포함합니다.

이동: 컨테이너: 서버는 선택적으로 다음의 up 링크 변경을 지원할 수 있습니다: 컨테이너. 또한 반드시 지원 여부를 나타내야 하며, Container를 다음의 appliesTo 속성에 포함합니다: MoveResource 기능. 다음이 이동하면, 컨테이너, 하위 항목도 함께 이동하며, 하위 항목의 식별자에는 이동한 다음의 식별자와 동일한 요구 사항이 적용됩니다: 컨테이너. 다음의 이동은 지원하지만, 데이터 리소스, 다음의 이동은 지원하지 않는 서버는, 컨테이너, 반드시 409 Conflict와 같은 적절한 4xx 상태 코드로 해당 요청을 거부해야 하며, 절대로 Container를 appliesTo 속성에 포함해서는 안 됩니다.

인가: 서버는 절대로 up 링크에 변경을 적용해서는 안 됩니다. 단, 요청하는 에이전트가 다음 두 작업을 모두 수행하도록 인가된 경우는 예외입니다: 리소스 삭제 작업을 이동할 리소스에 수행하는 것과, 리소스 생성 작업을 목적지에서 수행하는 것입니다: 컨테이너.

다음이 이동하면, 컨테이너, 해당 컨테이너만이 부모가 변경되는 리소스입니다. 하위 항목은 서로에 대한 상대적 위치를 유지하며, 서버가 식별자를 보존하는 경우 식별자도 유지합니다. 따라서 에이전트는 목적지에서 각 하위 항목을 다시 생성하도록 인가받을 필요가 없습니다. 그러나 해당 하위 항목에 적용되는 정책은 변경될 수 있습니다. 접근은 흔히 다음 내의 위치를 기준으로 제어되기 때문입니다: 포함 관계 계층. 이러한 이유로, 다음을 이동하는 데 필요한 인가는 컨테이너, 해당 대상을 삭제하는 데 필요한 인가입니다. 재귀적으로 삭제하는 경우이며, 이는 다음에 설명되어 있습니다: 9.5 리소스 삭제. 여기에 목적지에서 생성하는 데 필요한 인가도 있어야 합니다: 컨테이너. 서버는 반드시 해당 인가를 전체 하위 트리에 대해 평가한 후 변경을 적용해야 하며, 절대로 변경을 부분적으로 적용해서는 안 됩니다.

예시(데이터 리소스를 다른 컨테이너로 이동): 이 예시에서 저장소는 다음을 반영하지 않는 불투명한 식별자를 할당합니다: 포함 관계. 이동할 리소스는 https://storage.example/f8c3de3d로 식별되며, 해당 링크 집합 리소스는 https://storage.example/9b1e07a4로, 출발지와 목적지의 컨테이너는 https://storage.example/1d4f8a02 및 https://storage.example/c2a71f60으로 각각 식별됩니다. 클라이언트는 다음을 읽었으며, 링크 집합 리소스, 여기서 up 링크는 첫 번째 링크 맥락의 첫 번째 대상 객체입니다.

PATCH /9b1e07a4 HTTP/1.1
Host: storage.example
Authorization: Bearer <token>
Content-Type: application/json-patch+json
If-Match: "meta-v3"

[
  { "op": "replace", "path": "/linkset/0/up/0/href", "value": "https://storage.example/c2a71f60" }
]

클라이언트가 인가되었고 목적지인 다음이 컨테이너 존재한다고 가정하면, 서버는 리소스를 https://storage.example/1d4f8a02의 items 목록에서 제거하고, https://storage.example/c2a71f60의 items 목록에 추가하며, 다음을 갱신합니다: 링크 집합 리소스. 이들은 원자적으로 수행됩니다:

HTTP/1.1 204 No Content
ETag: "meta-v4"
Link: <https://storage.example/c2a71f60>; rel="up"

리소스는 계속 https://storage.example/f8c3de3d에서 이용할 수 있으며, 이제 다음의 멤버입니다: https://storage.example/c2a71f60. 리소스의 식별자는 자신의 위치를 계층 내에서 인코딩한 적이 없으므로, 이동은 다음에서만 관찰할 수 있습니다: 포함 관계 메타데이터.

예시(서버가 새 식별자를 할당하는 이동):

PATCH /alice/notes/shoppinglist.txt.meta HTTP/1.1
Host: example.com
Authorization: Bearer <token>
Content-Type: application/json-patch+json
If-Match: "meta-v3"

[
  { "op": "replace", "path": "/linkset/0/up/0/href", "value": "/alice/archive/" }
]

다음에서 식별자를 도출하는 서버는, 포함 관계 계층, 따라서 "preservesIdentifier": false를 알리며, 식별자를 보존할 수 없습니다. 서버는 결과 식별자를 갱신된 다음에 보고합니다: 링크 집합 리소스:

HTTP/1.1 200 OK
Content-Type: application/linkset+json
Content-Location: /alice/archive/shoppinglist.txt.meta
ETag: "meta-v4"

{
  "linkset": [{
    "anchor": "/alice/archive/shoppinglist.txt",
    "up": [{ "href": "/alice/archive/" }],
    "linkset": [{ "href": "/alice/archive/shoppinglist.txt.meta",
                  "type": "application/linkset+json" }]
  }]
}

예시(컨테이너를 자신의 하위 항목 중 하나로 이동):

PATCH /alice/notes/.meta HTTP/1.1
Host: example.com
Authorization: Bearer <token>
Content-Type: application/json-patch+json
If-Match: "meta-v7"

[
  { "op": "replace", "path": "/linkset/0/up/0/href", "value": "/alice/notes/2026/" }
]

서버는 갱신을 거부합니다. 다음에 순환이 생기기 때문입니다: 포함 관계 계층:

HTTP/1.1 409 Conflict
Content-Type: application/problem+json

{
  "title": "컨테이너를 자신의 하위 항목 중 하나로 이동할 수 없습니다",
  "status": 409,
  "detail": "/alice/notes/2026/은 /alice/notes/의 하위 항목입니다"
}

알림: 리소스 이동 지원을 알리고 알림을 내보내는 서버는 가급적 성공한 이동을 하나의 Move 활동으로 설명하는 것이 좋습니다. 이는 다음에 설명되어 있으며, 10.2.3 활동 유형, 별도의 Delete 및 Create 활동 대신 사용합니다.

이 표는 일반적인 LWS 응답(출처: 8절)을 HTTP 상태 코드와 페이로드에 매핑하여 일관성을 유지하며, 다음과 같은 구체적인 상황을 반영합니다: 페이지 나누기, 조건부 요청, 할당량 제약 및 메타데이터 통합:

리소스에 접근할 권한이 없는 클라이언트에게 리소스 존재 여부를 공개하고 싶지 않은 서버는 [RFC9110]에 설명된 대로 403 Forbidden 대신 404 Not Found로 응답할 수 있다.

저장소는 알림을 선택적으로 지원할 수 있습니다. 알림을 지원하는 저장소는 반드시 자신의 다음 리소스의 service 배열에 서비스 객체를 명시해야 합니다: 저장소 설명 리소스. 해당 객체의 type은 NotificationService여야 합니다.

서비스 객체는 반드시 serviceEndpoint 속성을 포함해야 하며, 그 값은 구독 엔드포인트의 URI입니다. 서비스 객체는 또한 반드시 다음을 포함해야 합니다: 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"
    ]
  }]
}

알림은 JSON-LD 문서로 표현되며, Notification 유형을 가집니다. 봉투에는 전달 맥락에 관한 메타데이터가 담기며, 활동 스트림 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"
    }
  ]
}

알림을 받기 위해 구독자는 구독을 생성하며, 요청을 보냅니다. 인증된 POST 요청을 serviceEndpoint로 보내며, 해당 속성은 NotificationService에 속합니다. 요청 본문은 반드시 다음을 준수해야 합니다: 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"
}

저장소는 선택적으로 다음에 대한 지원을 알릴 수 있습니다: 접근 요청 및 접근 권한 부여, 자신의 저장소 설명 리소스에서 알립니다. 이러한 지원을 알리는 경우, 서비스 객체는 다음의 엔드포인트를 설명하며, 접근 요청, 반드시 다음을 가져야 합니다: type, 그 값은 문자열 AccessRequestService여야 합니다. 또한 다음의 엔드포인트를 설명하는 서비스 객체는 접근 권한 부여, 반드시 다음을 가져야 합니다: type, 그 값은 문자열 AccessGrantService여야 합니다. 서비스 객체는 가급적 conformsTo 속성을 포함하는 것이 좋으며, 그 값은 컬렉션입니다. 하나 이상의 URI로 구성되며, 다음을 식별합니다: 접근 프로파일, 해당 엔드포인트에서 지원하는 프로파일입니다. 추가 속성을 선택적으로 포함할 수 있습니다:

{
  "@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 접근 프로파일.

다음 예시는 접근 요청을 보여줍니다. 이 예시는 다음에 정의된 JSON-LD 직렬화를 사용하여 표시됩니다: 11.4.1 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"
      }
    ]
  }]
}

다음 예시는 접근 권한 부여를 보여줍니다. 이 예시는 다음에 정의된 JSON-LD 직렬화를 사용하여 표시됩니다: 11.4.1 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 미디어 타입은 다음 문서 형식을 특수화한 문서를 식별합니다: W3C 제어 식별자 문서 [CID-1.0]. 이 문서는 LWS 어휘로 확장됩니다.

LWS 컨테이너 표현은 반드시 미디어 타입 application/lws+json을 지원해야 합니다.

LWS 컨테이너 표현은 JSON-LD 규칙을 사용하지만, LWS의 제약 조건과 요구 사항은 별도의 미디어 타입 사용을 정당화합니다.

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"
    }
  ]
}