Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Representation URLs and interactions #109

Closed
csarven opened this issue Nov 5, 2019 · 30 comments
Closed

Representation URLs and interactions #109

csarven opened this issue Nov 5, 2019 · 30 comments

Comments

@csarven
Copy link
Member

csarven commented Nov 5, 2019

Should a resource's representation URL(s):

  • exist?
  • if exists, should a resource advertise it through Content-Location?
  • if exists, should there be a redirect to the representation URL?
  • if the representation can be accessed, are there any constraints on i) reading ii) writing?
  • if writing is allowed on a representation URL, are there any side effects to other representation URLs?
@RubenVerborgh
Copy link
Member

My answers below:

  • exist?

MAY

  • if exists, should a resource advertise it through Content-Location?

SHOULD

  • if exists, should there be a redirect to the representation URL?

MAY

  • if the representation can be accessed, are there any constraints on i) reading ii) writing?

Reading: same as original resource.
Writing: I'd be inclined to say, only the specific representation then.

  • if writing is allowed on a representation URL, are there any side effects to other representation URLs?

Yes; representations stay connected to the resource.

@kjetilk
Copy link
Contributor

kjetilk commented Nov 5, 2019

  • if exists, should a resource advertise it through Content-Location?

SHOULD

With the guideline to avoid optional features, I am inclined to say MUST there. Other than that, I agree.

@csarven
Copy link
Member Author

csarven commented Nov 5, 2019

One design consideration is to minimise the number of interactions around a resource. From that perspective, representation URLs would not be exposed. Alternatively, if exposed, certain requests methods (basically writing; POST, PUT, PATCH) should be disallowed.

There are of course some advantages to exposing the representation URLs (eg caching), so making that optional seems reasonable, with the expectation that if supported, there is a required behaviour.

Based on that, one possibility:

  • exist?

MAY

  • if exists, should a resource advertise it through Content-Location?

MUST

  • if exists, should there be a redirect to the representation URL?

MUST NOT. (MAY could be an alternative but that explicitly introduces new affordances around the representation.)

  • if the representation can be accessed, are there any constraints on i) reading ii) writing?

Reading: don't see a need to set any. Anything in particular we need to consider?

Writing: 405. Writing must happen through the original resource. Side effect: don't have to specify or manage access controls for representations. Allow only includes read methods; GET, OPTIONS, HEAD.

  • if writing is allowed on a representation URL, are there any side effects to other representation URLs?

By only allowing writing to go through the resource, server implementation is somewhat simplified ie. doesn't have to bounce from writing to a particular representation and then generating equivalents for the other representation URLs. Things should exist and die with the resource. Bonus: avoid write access control policies around representations.

@RubenVerborgh
Copy link
Member

Writing: 405. Writing must happen through the original resource.

307?

@csarven
Copy link
Member Author

csarven commented Nov 5, 2019

307 sounds good. How well do user-agents/tools adhere to it?

@RubenVerborgh
Copy link
Member

Perfectly, as far as I know. 307 brought clarity where the others didn't.

@dmitrizagidulin
Copy link
Member

What is a Representation URL?

@kjetilk
Copy link
Contributor

kjetilk commented Nov 5, 2019

What is a Representation URL?

Following the examples in #69 , https://example.org/foo/index.html would be the URL of the representation of the resource https://example.org/foo/

@kjetilk
Copy link
Contributor

kjetilk commented Nov 5, 2019

Sorry, linked the wrong issue..., the one I meant to link was solid/solid-spec#134

@dmitrizagidulin
Copy link
Member

@kjetilk I see, thanks!

@csarven
Copy link
Member Author

csarven commented Nov 5, 2019

A minor note that this is not strictly about media types. Language would be another dimension in which a server may want to expose URLs for. Ditto Datetime.

@mikeadams1

This comment has been minimized.

@mikeadams1

This comment has been minimized.

@RubenVerborgh

This comment has been minimized.

@mikeadams1

This comment has been minimized.

@RubenVerborgh

This comment has been minimized.

@mikeadams1

This comment has been minimized.

@kjetilk
Copy link
Contributor

kjetilk commented Nov 15, 2019

Upon thinking about this a little further, I'm curious to understand whether this is a general issue, or if it is really just about index.html. Do we have use cases for anything beyond that?

@RubenVerborgh

This comment has been minimized.

@mikeadams1

This comment has been minimized.

@RubenVerborgh
Copy link
Member

@kjetilk Having representation-specific URLs is a generic issue. The fact that I can point to a certain Memento for instance. Or that I can point to a mistake in a JSON-LD representation.

@RubenVerborgh

This comment has been minimized.

@mikeadams1

This comment has been minimized.

@solid solid locked as off-topic and limited conversation to collaborators Nov 15, 2019
@RubenVerborgh

This comment has been minimized.

@kjetilk kjetilk added this to Under discussion in Specification Nov 15, 2019
@kjetilk
Copy link
Contributor

kjetilk commented Nov 15, 2019

@kjetilk Having representation-specific URLs is a generic issue. The fact that I can point to a certain Memento for instance. Or that I can point to a mistake in a JSON-LD representation.

Right, OK, good.

Apart from the apparent consensus in solid/solid-spec#134 that the ACL should be connected to the resource, not any particular representation, the main other problem I see is that a non-RDF resource usually wouldn't be representation of an RDF resource.

The reason I asked for whether it was just index.html is that this has some special properties: index.html would then be a representation of an LDP-C, and the LDP-C requires that certain minimal triples are present, including containment triples. HTML could easily accommodate for that using RDFa, but the generic case seems harder. Though, I suppose there usually isn't enforcement on that two different media types can be said to be a representation of a resource.

Perhaps we should have special requirements in the case where a LDP-NR is used to represent an LDP-RS, i.e. say something like "If an LDP-NR is used to represent and LDP-RS, then the representation MUST include a machine readable representation of the original RDF embedded in the representation."

This would deal with the case of index.html, in that people can stuff anything they want in there, but they would have to include RDFa to describe the container. As an implementation detail, the server could manipulate the DOM in an output filter to add it if not already present.

@solid solid unlocked this conversation Nov 16, 2019
@csarven
Copy link
Member Author

csarven commented Nov 17, 2019

re index ("special handling"):

@csarven
Copy link
Member Author

csarven commented Dec 9, 2019

There is no need to specify index.* as a special case: #69 (comment)

@michielbdejong
Copy link
Contributor

michielbdejong commented Sep 6, 2020

I see no need to complicate the life of app devs with something like Content-Location. Why not just use the same URL for all representations, and use content negotiation to retrieve them?

@RubenVerborgh
Copy link
Member

I see no need to complicate the life of app devs with something like Content-Location.

We're not. Nobody needs to touch it.

Why not just use the same URL for all representations, and use content negotiation to retrieve them?

We are; note that those are not contradictions. We can have both:

  • one resource URL that connegs to different representations
  • URLs for every individual representation (indicated via Content-Location)

Then app devs who want to do conneg, can. Those who don't want, don't have to. Choice is easy.

An actual use case for per-representation URLs is legacy systems (a real one I have now is a calendar system) that do not negotiate.

@csarven
Copy link
Member Author

csarven commented Oct 18, 2020

Resolved by #196

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Specification
  
Done
Development

No branches or pull requests

7 participants