Back to feed
Renewal·마흔의 생활코딩

Web 3.0 Broad-and-Shallow — Solid Protocol (feat. WebID)

NS
normalstory
cover image

HTTP web standards

Solid servers and clients use HTTP web standards to securely exchange data over the internet

Category — Server — Client

HTTP/1.1 Conditional Requests MUST MAY
HTTP/1.1 Caching SHOULD MAY
HTTP/1.1 Range Requests MAY MAY
HTTP/1.1 Authentication MUST MUST
HTTP/2 SHOULD MAY
Content-Type    
(PUT, POST, PATCH requests without a Content-Type header are rejected with status code 400) MUST MUST
Use TLS connection    
(to secure communication with clients) Conform (recommended)  
(* use the https URI scheme) -  
* When supporting both URI schemes (http://, https://) http→https redirection  
(response with status code 301 and a Location header) -  

 

 

 

 

 

URI

Uniform Resource Identifier — a unified resource identifier

  1. A string that uniquely identifies a resource (a file, a web page, a web service, etc.) on the web
    • Represents hierarchical relationships and enables relative references
    • Ending with (/) denotes a container resource
    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 — the slash (/) character in the URI path
  3. A string that uniquely identifies a resource (a file, a web page, a web service, etc.) on the web → URI Persistence — non-normative spec
    • URI Reuse
      • Regardless of how a resource is created, it is suggested that the server SHOULD NOT reuse a URI
      • There are specific cases where a URI can be restored when identifying the same resource, but this only applies when it conforms to URI persistence in web architecture (i.e., when it points to the same resource)
    • Disabling URI Reuse
      • If a server deletes a resource and intends to no longer use that URI,
      • → Returns a **410** status code to the client
      • Indicates that the resource has been permanently removed, and is used to prevent URI reuse
  4. Uniquely = same URI = must always point to the same resource
  5. URI Ownership
  6. Does not address the relationship between storage owners and URI ownership

 

 

Resources

  • 1. Storage Resource
    • The server MUST provide one or more storages.
    • Each storage is a storage resource (pim:Storage) and serves as the root container of all self-contained resources.
      • Mermaid
      • 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
    • If the server supports multiple storages, the URIs MUST be allocated in non-overlapping spaces.
    • The process of finding a resource's storage through client-server communication
    • 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
    • (For HTTP GET, HEAD, and OPTIONS requests targeting resources in the storage,) in the response
      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>"
      
    • (For HTTP HEAD or GET requests targeting the root container,) in the response
      HTTP/1.1 200 OK
      Link: <http://www.example.com/owner>; rel="<http://www.w3.org/ns/solid/terms#owner>"
      
  • The place where data owned by the user is stored and managed
    • 2. Resource Containment
      • The representation and behavior of containers correspond to LDP Basic Containers and are supported by the server
      • A collection of linked resources to help with resource discovery and lifecycle management
      • Within the path-name hierarchy
        • There is a 1-1 correspondence between container triples and relative references
          • /container: the main container
          • /container/resource1: the first resource
          • /container/resource2: the second resource
          In this structure, **/container** is the main container, and **/container/resource1** and **/container/resource2** are resources belonging to this container.Container Triple: Relative references:
          • /container/resource1: the first resource inside the /container
          • /container/resource2: the second resource inside the /container
          In this way, the container triple and the relative references have a 1-1 correspondence. There is a clear correspondence between the main container (/container) and the resources within it (resource1, resource2), and this plays an important role in resource discovery and management on the Solid platform.
        • </aside>
        • The container triple and relative references that represent this structure can be expressed as follows:
        • <aside> ?️ Example structure
      • All resources in the container
      • Discoverable (a resource without a source cannot exist)
      • (For HEAD and GET requests targeting a container,) in the response
      • The server MAY determine the value of the HTTP Last-Modified header field based on changes to the container triangle.
      • Contained Resource Metadata
      • This is to support client navigation and application interaction
    • 3. Auxiliary Resources
    • **The Subject Resource** is

This English version was translated by Claude.

친절한 찰쓰씨
Written by
친절한 찰쓰씨

Pleasant Charles — UI/UX researcher at AIT. Keeping notes on design, planning, and slow days here since 2010.

More on the author's page

Keep reading

Renewal

Steadily, for the long haul, without burning out

Mar 31, 2026·9 min
Renewal

Tech-life balance

Feb 7, 2026·3 min
Renewal

Humanality, by Park Jeong-ryeol

Feb 7, 2026·11 min