Skip to content
This repository was archived by the owner on Apr 13, 2022. It is now read-only.

Commit 0dfc010

Browse files
committed
Restrict globbing to /*
Closes #147.
1 parent b941ff7 commit 0dfc010

File tree

1 file changed

+39
-52
lines changed

1 file changed

+39
-52
lines changed

api-rest.md

Lines changed: 39 additions & 52 deletions
Original file line numberDiff line numberDiff line change
@@ -58,91 +58,78 @@ HTTP/1.1 200 OK
5858
<http://www.w3.org/ns/posix/stat#size> "780" .
5959
```
6060

61-
#### Globbing (inlining on GET)
61+
#### Globbing (`GET` the merged RDF graph of a container)
6262

6363
**Note: this feature is _at risk_ of being
6464
[changed](https://github.com/solid/solid-spec/pull/148)
6565
or [removed](https://github.com/solid/solid-spec/pull/151).
6666
Please join the discussion.
6767
Code depending on this will still work for now.**
6868

69-
We have found that in some cases, using the existing LDP features was not
70-
enough. For instance, to optimize certain applications we needed to aggregate
71-
all RDF resources from a container and retrieve them with a single GET
72-
operation. We implemented this feature on the servers and decided to call it
73-
"globbing". Similar to [UNIX shell
74-
glob](https://en.wikipedia.org/wiki/Glob_(programming)), doing a GET on any URI
75-
which ends with a `*` will return an aggregate view of all the resources that
76-
match the indicated pattern.
77-
78-
For example, let's assume that `/data/res1` and `/data/res2` are two resources
79-
containing one triple each, which defines their type as follows:
80-
81-
For *res1*:
69+
To optimize certain applications,
70+
this specification defines a single `GET` operation
71+
that provides access to an aggregation of the RDF resources in a container.
72+
We refer to this feature as _globbing_,
73+
since it provides a subset of the functionality
74+
offered by the [UNIX shell glob](https://en.wikipedia.org/wiki/Glob_(programming)).
75+
Consider a container to which the user has _Read_ access,
76+
which will have a URL ending in `/`.
77+
If we append a `*` to that URL (so it ends in `/*`),
78+
we obtain the URL of a resource that,
79+
in response to a `GET` request,
80+
returns the [RDF graph merge](https://www.w3.org/TR/rdf-mt/#graphdefs)
81+
of all of the container's direct child resources
82+
that are available in an RDF format
83+
and for which the user has _Read_ access.
84+
Resources with syntax errors can be ignored or be partially included,
85+
but they do not cause a failure.
86+
The response can contain additional metadata about the container,
87+
such as the list of resources.
88+
89+
For example, consider a container `/data` that contains the following resources:
90+
- `resource1.ttl`
91+
- `resource2.ttl`
92+
- `hidden3.ttl`
93+
- `resource4.txt`
94+
95+
The user performing the request had read access to `/data`,
96+
`resource1.ttl` and `resource2.ttl`,
97+
but not to `hidden3.ttl`.
98+
Let's assume that `/data/resource1.ttl` and `/data/resource2.ttl`
99+
contain one triple each:
82100

83101
```ttl
84102
<> a <https://example.org/ns/type#One> .
85103
```
86104

87-
For *res2*:
88-
89105
```ttl
90106
<> a <https://example.org/ns/type#Two> .
91107
```
92108

93-
If one would like to fetch all resources of a container beginning with `res`
94-
(e.g. `/data/res1`, `/data/res2`) in one request, they could do a GET on
95-
`/data/res*` as follows.
96-
97-
REQUEST:
98-
99-
```http
100-
GET /data/res* HTTP/1.1
101-
Host: example.org
102-
```
103-
104-
RESPONSE:
105-
106-
```http
107-
HTTP/1.1 200 OK
108-
```
109-
```ttl
110-
<res1>
111-
a <https://example.org/ns/type#One> .
112-
113-
<res2>
114-
a <https://example.org/ns/type#Two> .
115-
```
116-
117-
Alternatively, one could ask the server to inline *all* resources of a
118-
container, which includes the triples corresponding to the container itself:
119-
120-
REQUEST:
109+
Then a request to `/data/*`
110+
will return a serialization of the [RDF graph merge](https://www.w3.org/TR/rdf-mt/#graphdefs)
111+
of the datasets contained in `resource1.ttl` and `resource2.ttl`:
121112

122113
```http
123114
GET /data/* HTTP/1.1
124115
Host: example.org
125116
```
126117

127-
RESPONSE:
128-
129118
```http
130119
HTTP/1.1 200 OK
131120
```
132121
```ttl
133122
<>
134123
a <http://www.w3.org/ns/ldp#BasicContainer> ;
135-
<http://www.w3.org/ns/ldp#contains> <res1>, <res2> .
124+
<http://www.w3.org/ns/ldp#contains> <resource1.ttl>, <resource2.ttl> .
136125
137-
<res1>
126+
<resource1.ttl>
138127
a <https://example.org/ns/type#One> .
139128
140-
<res2>
129+
<resource2.ttl>
141130
a <https://example.org/ns/type#Two> .
142131
```
143132

144-
Note: the aggregation process is not currently recursive, therefore it will not
145-
apply to children containers.
146133

147134
### Alternative: using SPARQL
148135

@@ -392,4 +379,4 @@ Servers SHOULD send a WAC-Allow response header on HEAD and GET, with a value li
392379
```http
393380
WAC-Allow: user="read write append control",public="read"
394381
```
395-
In general, the format is `user="` + user-permissions = `",public="` + public-permissions + `"`. User-permissions and public-permissions should both be space-separated lists, containing a subset of ['read', 'write', 'append', 'control']. If 'write' is present then 'append' should also be present.
382+
In general, the format is `user="` + user-permissions = `",public="` + public-permissions + `"`. User-permissions and public-permissions should both be space-separated lists, containing a subset of ['read', 'write', 'append', 'control']. If 'write' is present then 'append' should also be present.

0 commit comments

Comments
 (0)