You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While I was implementing pyldn, a compliant receiver, it was a bit unclear how receivers must respond to GET requests against notification URIs.
I see this bit was added meanwhile as a receiver responsibility, which already helps:
Responds to GET requests made to the individual notification URLs with JSON-LD (or optionally other serializations).
Section 3.3.2 specifies though how a receiver should respond to GET requests against inbox URIs, but not what to do against GET requests to notification URIs. This bit
Each notification must be an RDF source. If non-RDF resources are returned, the consumer may ignore them.
suggests that the receiver must make the notifications available, and answer HTTP 200 OK to valid notification URIs and HTTP 4xx where applicable; but I felt this wasn't specific enough in the draft. Also, I find the requirement on making notifications RDF sources a bit over constraining. Currently pyldn uses notification URIs as graph names, and stores the payloads' triples within those. It's a bit unclear whether this is compliant with the spec or not. I think it might also create issues when consumers ask for serializations that do not support quads (e.g. curl -X GET -H'Accept: application/n-triples' http://example.org/inbox/1)
Some of these are also implied by section 3.4 Consuming, but as a receiver implementor I would expect all receiver requirements to be described in section 3.3.
The text was updated successfully, but these errors were encountered:
Treating the notification URI as the graph name is one way of doing it, and the way you do it is perfectly fine. The resource itself is a graph in and of itself where it might have its description in triples or quads (multiple graphs in the resource).
While I was implementing pyldn, a compliant receiver, it was a bit unclear how receivers must respond to GET requests against notification URIs.
I see this bit was added meanwhile as a receiver responsibility, which already helps:
Section 3.3.2 specifies though how a receiver should respond to GET requests against inbox URIs, but not what to do against GET requests to notification URIs. This bit
suggests that the receiver must make the notifications available, and answer HTTP 200 OK to valid notification URIs and HTTP 4xx where applicable; but I felt this wasn't specific enough in the draft. Also, I find the requirement on making notifications RDF sources a bit over constraining. Currently pyldn uses notification URIs as graph names, and stores the payloads' triples within those. It's a bit unclear whether this is compliant with the spec or not. I think it might also create issues when consumers ask for serializations that do not support quads (e.g.
curl -X GET -H'Accept: application/n-triples' http://example.org/inbox/1
)Some of these are also implied by section 3.4 Consuming, but as a receiver implementor I would expect all receiver requirements to be described in section 3.3.
The text was updated successfully, but these errors were encountered: