Store and fetch your first resource in a pod

Two HTTP requests.

Where this transcript comes from, said plainly

It was run against a pod started on a laptop, two commands, not against our deployed host. Writing to ours needs an authenticated session, so a transcript from there would need credentials you do not have and could not check.

We would rather show you something you can reproduce exactly than something you have to believe.

Write

$ curl -X PUT http://localhost:3000/hello.ttl \
    -H 'Content-Type: text/turtle' \
    --data-raw '<#it> <http://schema.org/name> "hello" .'

201 Created

That is the whole write path. The resource is named by its URL; PUT puts it there.

Read

$ curl http://localhost:3000/hello.ttl
<#it> <http://schema.org/name> "hello" .

200 OK

The same bytes come back. No envelope, no wrapper, no identifier of ours anywhere in it.

CONTROL, because a server that returns 200 for everything would produce the same screenshot:

$ curl -o /dev/null -w '%{http_code}' http://localhost:3000/never-created.ttl
404

Absent and stored are distinguished. Without that line, the two requests above prove nothing.

What the response headers tell a client

Allow: OPTIONS, HEAD, GET, PATCH, PUT, DELETE
Accept-Patch: text/n3, application/sparql-update
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Link: <.../hello.ttl.acl>; rel="acl"
WAC-Allow: user="append control read write", public="append control read write"

Four things a stranger's tool learns without being told anything about us: what methods are allowed, that the resource can be patched and in which formats, that it is an LDP resource, and where its access-control document lives.

Two honest notes on that block. We advertised patching and did not exercise it: the header is the server's claim, not our measurement. And WAC-Allow shows a wide-open default: this pod grants everyone all four modes, which is a laptop-only arrangement.

Why "it is just HTTP" is the interesting part

There is no proprietary API here. The verbs are the web's verbs, the identifier is a URL, and the content type is negotiated. A tool written before Solid existed can read a resource out of a pod.

That property is Solid's, and it is the strongest argument in the entire model, it is also the one that goes against our own identifier design, which needs a client that speaks our method.

Doing this against our deployment

You need an authenticated session, because our deployed host runs a per-pod layout where the root is not open. The interface does it for you, creating a folder and uploading a file is the same two operations behind a screen.

And a warning about debugging it: on our host an unknown path returns 401, not 404. A refusal there tells you nothing about whether the resource exists, which is the opposite of the local behaviour you just saw. Why that is.