Normal Storya quiet journal
← 피드로 돌아가기
새로워지기·마흔의 생활코딩

Web3.0 지대넓얕 - Solid Protocol( feat.WebID)

NS
normalstory
2023년 12월 23일·5 분 읽기
표지 이미지

HTTP 웹 표준

Solid 서버 및 클라이언트는 인터넷을 통해 데이터를 안전하게 교환하기 위해 HTTP 웹 표준 사용

구분 서버 클라이언트

HTTP/1.1 조건부 요청 필수 선택
HTTP/1.1 캐싱 권장 선택
HTTP/1.1 범위 요청 선택 선택
HTTP/1.1 인증 필수 필수
HTTP/2 권장 선택
Content-Type    
( Content-Type 헤더 없는 PUT, POST, PATCH 요청은 400 상태코드로 거부) 필수 필수
TLS 연결 사용    
(for 클라이언트와의 통신을 보안) 준수(권장)  
(* https URI scheme 사용) -  
* 두 가지 URI scheme( http://, https:// ) 모두 지원하는 경우 http→https 리다이렉션  
( 301 상태 코드와 Location 헤더를 포함한 응답) -  

 

 

 

 

 

URI

Uniform Resource Identifier 통합 자원 식별자

  1. 웹 상의 리소스( 파일, 웹 페이지, 웹 서비스 등)를 고유하게 식별하는 문자열
    • 계층적인 관계를 나타내고 상대 참조를 가능하게 함
    • (/)로 끝나면 컨테이너 리소스를 나타냄
    URI Scheme URI Domain Path
    https:// www.example.com/ /blog  
    URI Scheme URI Domain Path Fragment
    https:// www.example.com/ /page #section2
    URI Scheme URI Domain Path Query String
    http:// www.example.com/ /search ?q=keyword
  2. → URI Slash Semantics URI 경로에서 슬래시 (/) 문자
  3. 웹 상의 리소스( 파일, 웹 페이지, 웹 서비스 등)를 고유하게 식별하는 문자열→ URI Persistence 비정규 스펙
    • URI Reuse
      • 리소스가 생성되는 방식에 관계없이 서버는 URI를 재사용하지 말아야 함을 제안
      • 동일한 리소스를 식별할 때 URI를 복원할 수 있는 특정 경우가 있지만, 이는 웹 아키텍처의 URI 지속성( 동일한 리소스를 가리키는 경우)에 부합하는 경우에만 해당
    • Disabling URI Reuse
      • 서버는 리소스를 삭제하고 해당 URI를 더 이상 사용하지 않으려는 경우,
      • → 클라이언트에게 **410**상태 코드를 반환
      • 리소스가 영구적으로 제거되었음을 나타내며, URI 재사용을 막는 데 사용
  4. → 고유하게 = 같은 URI = 항상 같은 리소스를 가리켜야 함을 의미
  5. URI Ownership
  6. 저장소 소유자와 URI 소유권 간의 관계에 대한 내용을 다루지 않음

 

 

Resources

  • 1. Storage Resource 저장소 리소스
    • 서버는 하나 이상의 저장소를 제공해야 합니다.
    • 각 저장소는 저장소 리소스 (pim:Storage)로, 자체 포함된 모든 리소스의 루트 컨테이너 역할을 합니다.
      • Memaid
      • graph TD subgraph Storage 3 root1["Root Container 3"] resource1["Resource d"] resource2["Resource "] root1 --> resource1 root1 --> resource2 end subgraph Storage 2 root2["Root Container 2"] resource3["Resource c"] root2 --> resource3 end subgraph Storage 1 root3["Root Container 1"] resource4["Resource a"] resource5["Resource b"] root3 --> resource4 root3 --> resource5 end
    • 서버가 다중 저장소를 지원하는 경우, URI는 중첩되지 않는 공간에 할당되어야 합니다.
    • 클라이언트 서버간 통신을 통해 리소스의 저장소를 찾는 과정
    • sequenceDiagram participant C participant S **C->>S:** HTTP GET **/some/resource** S->>C: HTTP 200 OK S->>C: Link: <http://www.example.com/**some**>; rel="other" **C->>S:** HTTP GET /**some** S->>C: HTTP 200 OK S->>C: Link: <http://www.example.com**/**>; rel="another" **C->>S:** HTTP GET **/ (Root)** S->>C: HTTP 200 OK S->>C: Link: <http://www.example.com/**storage**>; rel="type" **C->>S:** HTTP GET /**storage** S->>C: HTTP 200 OK S->>C: Content-Type: text/turtle **C->>S: Parsing RDF Response** Note over C, S: Found relation **rel="type"** targeting **<http://www.w3.org/ns/pim/space#storage**>
    Servers MUST
    • (스토리지의 리소스를 대상으로 하는)HTTP GET, HEAD 및 OPTIONS 요청의 응답에 
      HTTP/1.1 200 OK
Link: <http://www.example.com/storageDescription>; rel="<http://www.w3.org/ns/solid/terms#storageDescription>"
Link: <http://www.example.com/owner>; rel="<http://www.w3.org/ns/solid/terms#owner>"
    • (루트 컨테이너를 대상으로 하는) HTTP HEAD 또는 GET 요청의 응답에 
      HTTP/1.1 200 OK
Link: <http://www.example.com/owner>; rel="<http://www.w3.org/ns/solid/terms#owner>"
  • 사용자가 소유한 데이터를 저장하고 관리하는 곳
  • 2. Resource Containment
    • 컨테이너컨테이너의 표현과 동작은 LDP 기본 컨테이너에 해당하며 서버에서 지원
    • 리소스 검색 및 수명 주기 관리를 돕기 위해 연결된 리소스 모음
    • 경로 이름 계층 구조 내에서
      • 컨테이너 트리플과 상대 참조 사이에는 1-1 대응 관계
        • /container: 주요 컨테이너
        • /container/resource1: 첫 번째 리소스
        • /container/resource2: 두 번째 리소스
        이 구조에서 **/container**가 주요 컨테이너이고, **/container/resource1**와 **/container/resource2**는 이 컨테이너에 속한 리소스입니다.컨테이너 트리플 (Container Triple):
        • 주체(Subject): 주요 컨테이너(/container)의 URI
        • 관계(Predicate): rdf:type
        • 객체(Object): 컨테이너 타입의 URI(http://www.w3.org/ns/iana/media-types/{+iana-media-type}#Resource)
        상대 참조:
        • /container/resource1: /container 컨테이너 내에 있는 첫 번째 리소스
        • /container/resource2: /container 컨테이너 내에 있는 두 번째 리소스
        이렇게 컨테이너 트리플과 상대 참조가 1-1 대응 관계를 가지고 있습니다. 주요 컨테이너(/container)와 그 내부의 리소스(resource1, resource2) 간에는 명확한 대응이 있으며, 이것은 Solid 플랫폼에서 리소스 검색 및 관리에 중요한 역할을 합니다.
      • </aside>
      • 이러한 구조를 나타내는 컨테이너 트리플 및 상대 참조는 다음과 같이 나타낼 수 있습니다:
      • <aside> ?️ 예시 구조
    • 컨테이너에서 모든 리소스
    • 검색 가능(출처 없는 리소스는 있을 수 없음)
    • (컨테이너를 대상으로 하는) HEAD 및 GET 요청에 대한 응답으로
    • 서버는 컨테이너 트라이앵글의 변경 사항을 기반으로 HTTP Last-Modified 헤더 필드의 값을 결정할 수 있습니다.
    • Contained Resource Metadata
    • 이것은 클라이언트 탐색 및 응용 프로그램 상호 작용을 지원하기 위함
  • 3. Auxiliary Resources
  • **주제 리소스(Subject Resource)**는
친절한 찰쓰씨
글쓴이
친절한 찰쓰씨
친절한 찰쓰씨 · 일상 UX 디자이너
기획·디자인·단상을 조용히 기록합니다.
작가 페이지에서 더 보기 →

이어서 읽기

새로워지기

꾸준히, 오래, 지치지 않고

Mar 31, 2026·8 분
새로워지기

테크 라이프 발란스

Feb 7, 2026·3 분
새로워지기

휴탈리티 박정렬

Feb 7, 2026·11 분