Specify POST #108
Comments
|
I am happy to adjust the Trellis behavior to whatever gets specified here, but I will describe the current behavior in the context of your questions.
Respond with
Respond with
For a successful request (i.e.
The body of the request (the raw byte stream) is used to create the new resource at the location hinted at with a
The server uses implementation-specific heuristics to assign an interaction model. I.e. if the |
|
Raised by @ericprud ( https://gitter.im/solid/specification?at=5dcd102092a84f79fe6477bb ): Should a |
|
Indeed, LDP defines So, my proposal follows somewhat like the setup of #40 :
|
By "RDF", are you referring to server-managed triples or the other representations of the same resource? Why [POST] "replace" exactly? RDF Source or Non-RDF Source Update cases use append. Requiring different access modes, depending on Content-Type and optionally Link headers, seems awkward. Is there even a way to set a policy like that in ACL? Otherwise, setting acl:Write on the container (and by default its members) just so that it can be updated in HTML seems problematic. Besides those concerns, I agree with the setup. |
I was thinking the entire RDF representation, to easily distinguish in a non-LDPy way...
Simply because
Yeah, I agree, it is awkward. My thinking is that you would most probably usually replace the HTML representation (#69 ), editions is managed client side, so you If we resolve that you can replace an HTML representation through |
I don't understand. Can you please clarify?
If representations have their URLs, it would be possible to set different access modes. However, the direction we are taking sets the policy on the effective request URI which applies to all representation URLs. Simpler to keep all POST updates to append.
I don't see the key difference. Both approaches essentially attempt to replace a container that way. Looking at it from the other direction, if so desired, the same rule can be applied to POST, PUT, PATCH ie. don't allow server-managed triples to be altered, irrespective of the mediatype. Possible to just ignore or fail universally. |
OK. If we say "server-managed triples" that references the LDP specification, an implementation has to understand what is meant by that, if we say "entire RDF representation", that's just a media type, much less to understand. However, I suppose what makes the actual complexity is something we will find out when we write the spec, it is thus something we can defer until the drafting phase.
My main concern is that the security usability around access modes for different representation URLs is going to be really bad unless we put a lot of effort into it. We then have to make sure the end result when managing authz isn't confusing. That's not to say that we shouldn't resolve #109 , it is just that it is a much bigger topic when authz is involved. If we just have the container URL, and all manipulations are on that, it is much easier, you know exactly what rules apply.
The key difference is that |
So we agree. Shouldn't design to have representations with different access modes.
I meant beyond the literal difference between POST and PUT. If POST HTML is spec'd to act like a write/replace operation, it will generally have the same affect as PUT anything to write/replace. And so they both have to deal with not touching the RDF/server-managed triples. |
|
Create a new resource in It is not possible to append information to Create Slug is required in order to append information to container with POST. |
|
Is this in a current implementation, or do you intend it as a normative statement? |
|
It is what I've inferred from the foundations. POST to target resource that's a container will add a new resource to a container. So, how can the root container be targeted for the purpose of update (append)? I'm not aware of a server allowing a root container update (append) with POST, so that's within normal behaviour. To close any potential gaps, the question would be if updating the root container should be prohibited with POST. If PUT and PATCH can and allowed, it is probably fine with POST as well. We can devise a way of course but it doesn't seem to be possible at the moment. For non-root containers, it would be possible to update the container via Slug as the constructed effective request URI would be the desired container, although not necessarily guaranteed if for instance the server doesn't implement Slug or ignores it (aside: we can come back to that exact requirement). I'm not aware of a server capable of updating a non-root container with POST+Slug. |
|
Oh, I can see it now, you're right... I was confused, because I didn't understand what was appending to a resource and what was creating a resource (which is also appending a container). I my proposal, your first example would append that triple to the root container RDF representation. And that is, I acknowledge, inconsistent with what I said, that a I don't think we should prohibit or to append The former is a practice that has been common for a very long time on the Web but doesn't have a spec behind it AFAIK, the latter is a relatively novel interpretation of an old non-normative spec statement. I suspect the former is already implemented, I'll write a test for it... |
That's it. What I'm saying is that - based on agreed foundations - I don't see "append [payload] to the container RDF representation" possible unless Slug is purposed to target the desired effective request URI. Obviously that's not possible for the root container case as it stands. Either the request needs to pass additional information about the intention or we acknowledge that it is not possible to update root container with POST.
I'm not certain but that practice probably didn't permit more than one operation on the same effective request URI. |
|
How about using POST with That is for any container. |
|
Interesting idea! Just one thing: Currently, So, how about using Downside of that would be if the feature is already implemented, it would be a breaking change. |
|
I agree that the RFC wording emphasises create but append is not particularly prohibited. Server is already expected to create the identifier without Slug. |
|
Right. OK, so we have a couple of possibilities. Those are things that shouldn't block us from advancing to rought consensus, I think. Any other things that block us from that? |
|
No blockers. Some aspects will be worked out in drafting. By the way, appending with POST text/html is possible and generally useful with RDFa but not so with non-RDFa. POST text/html to an existing container should be interpreted as an append operation based on request's payload in RDFa - effectively allowing RDF Merge. If the payload doesn't encode an RDF graph, there is nothing to append. |
|
Tested, and found that i.e., NSS creates a resource with a server-assigned identifier if no |
I do not understand the consistant effort to treat anything-but-RDF as trash. RDFa must not be treated as RDF-plus-HTML, nor otherwise be handled as if the HTML is valueless. RDFa is HTML-plus-RDF, and the primary value of the resource is in the HTML, which value is increased by the inclusion of the RDF. RDF Merge is not appropriate for
|
I do not understand how anything that we've said can be interpreted as that. To the contrary, this effort is motivated by a "homepage" use case, where a user wants to write a homepage in HTML.
Of course.
Why do you say that?
Of course, just as we've specified.
Yes, that's what we've been saying. What algorithm do you want to use for that if you do not want to use RDF Merge?
Of course. |
What followed from the point of agreement at #108 (comment) was about container updates.. because it wasn't addressed. That's why I raised and the discussion moved. Whether it is possible to target a container for update with POST:
Re:
RFC doesn't restrict POST append to a Content-Type. So, if anything that's going on is Solid constraining the append to only RDF formats. But even for Solid, I was under the impression that append is not limited to RDF.. I see no reason provided that each use their own request semantics/algo. If we acknowledge that a container may not necessarily be an RDF Source, then we have to consider whether append is supposed to be about RDF or not. Having said that, if POST to append is only for RDF:
What do you think about #40 (comment) ?
Yes.
I thought we agreed on that already. Provided that update to container (to create a new resource) can be covered by append: #118 (comment) .
I don't have anything better at the moment either.. and yes, I can live with no container updates as well. It is still though important... giving a container a human-readable label is a natural expectation. -- Can we wrap this up? We have enough material here for draft criteria. We can resolve the finer details there. |
Right, but I took the conversation here as a broader discussion, one that is about what append operations imply on generic resources, not specifically containers.
No, but the RFC doesn't need a strict interpretation, as it doesn't have a concept of access control, so it can afford to be generic, we cannot, because we have to make sure that the
Hmmmm, append is certainly a useful operation on all kinds of resources, but surely, what an append implies certainly comes down to the semantics of the media type, or even the individual representation? For RDF, we have the luxury of the RDF merge, which is great. For HTML and JSON, you could envision that an append operation implies that the existing representation That's why I say that each media type needs its own append definition. For RDF we have one, lets go for that.
If we restrict ourselves to containers, then yes. For generic resources, I think the definition could be something like "if representation has a clear algorithm for append" or something.
Yeah... it could still be updated by
I agree. We will probably better advance with it more concrete now, and I think it is appropriate to put it down in draft text. |
I haven't digested everything subsequent to this yet, but this is important --
@ericprud's formulation must not be put in the spec, as written here. |
|
@TallTed , we can't have a generic server do everything that custom POST handler might do. Normally, I'd not want to bother handling POST on HTML at all, but folks seemed motivated to handle POSTs to index files. Given that, I don't see how we can do any more than provide a simple and predictable rule that clients can count on. So sure, clients might want POST to do arbitrarily complex operations; but I don't know how to specify a generic POST operation to do that. Got any ideas? |
|
Not sure it is POST on HTML that is the central issue, rather handle the RDFa that might be embedded in it, which should be handled like other RDF would. |
|
I agree that RDFa is our primary use case, but I don't think the presence or absence of RDFa affects the treatment of HTML. RDFa's value comes in it being interspersed in the HTML (otherwise, you may as well use a script with type=turlte or JSON). Suppose we have an index file: <html><head><title>My Stuff</title><style></style></head>
<body>
<h2 property="http://purl.org/dc/terms/title">Resource 1</h2>
<p>Date: <span property="http://purl.org/dc/terms/created">2011-09-10</span></p>
</body> </html>If we want to add Resource 2 and preserve the RDF, we can (in order of increasing effort and controversy):
And of course there's no-HTML-POST -- reject any POSTs with HTML target or body. |
|
Yes, indeed, the question is not whether it can be done, the question is whether we should, and if we should, then the question is when. My answer is "definitly not now" :-) To expand on the append-body, this suggest that there is a lot of freedom that servers could have in determining what an append would be, just like shapes for RDF. For example, one resource could determine that an append it its context would be to add another pair of I would question if this is a valid use of Solid, since Solid is mostly about manipulating RDF, and have apps that use RDF on the client side. In this case, we add to much smart to the server side. I don't see markup-target as a major undertaking, but I don't think we should define it, it should be up ot the server to template where they want to inject the RDFa data. They would probably have to do that anyway, but I believe the only normative thing we should say about it, is that the RDF representation has to be there for the #69 case. |
|
[Just laying out some things to consider.. and also for drafting, so bear with me.] I'd like to clarify some behaviours and variability related to Slug because it seems important. Assuming container create and/or update are desired with POST. Without the other headers (eg. Link) influencing the identifier, we have:
A server accepting Slug and keeping the value as is, the response of the following requests should be equivalent: That is, There is however a variability issue (or consideration) in the responses pertaining to effective request URIs where server ignores Slug. Hence, the above example may result in the creation of Client's request may either result in update So, what a poor client to do? First question is whether this kind of variability should exist in the design. Let's say it shouldn't. One way a nice server may be able to mitigate unexpected results for the client is to catch some of the cases. For instance, a server may ignore the Slug in determining an identifier, however, if detected, it can check for consistency. So: Here the client would like to create Yet another possible server behaviour is where Slug can only be used to update a container and that create will be rejected. Clients need to use PUT (simple) or PATCH (less simple) to create a container. So: Client's request may either update So, this is a matter of client's comfort in dealing with the consequences of using a Slug. Not using it is obvious and simple but there are cases in which it is definitely a nice to have. If create or update container via POST removed, that'd is another simplification. Almost done: alternatively, we raise the level of Slug requirement so that there is less variance in the responses. |
|
Actually, it seems I would want to challenge the premises of that post, @csarven :
My opinion is that
For creates, I think we exhausted the space in #128 (comment) |
Actually, I think you may have overlooked the premise and the statements there :) Put differently, if you still want to be able to create and update a container using POST, Slug is (probably) required (re #108 (comment) )
That'd be great. How? PUT, PATCH is a non issue obviously. The whole point of observing variability was due to Slug being MAY. And to help figure out where to draw the lines. I don't think whether Slug can be used for append or not is actually an issue - okay to dismiss the possibility of course. Let me put it this way, we define the append operation but in there we do have some "create" resource happening - at least the context being that a resource is created and added to container. We are using POST for the purpose of append, so whether the Slug is actually constrained to create (like stand alone resources) is a very specific view. (I'm not dismissing or disagreeing .. just saying that our definitions and reasoning is not super clear to make the call on Slug that way.) |
|
OK, then I don't understand where you are going, but I've returned it to Under discussion to clarify. In my head it is very simple: When updating, you don't use a That That's my position, what's wrong with that picture? |
|
Just to be clear, it makes sense to move to Under Discussion on the basis of us not completely clearing how to POST Container.Update and if so still desired. As documented above, I was merely exploring the boundaries to find a way to reconcile. So, yes, I do fully understand your position and there is nothing wrong with that picture. |
|
Hey! You scared the living daylights out of me, @csarven , I thought you were opening a much bigger can of worms! Is that picture something we can go for as rough consensus? |
|
Just stating my preference, not intending to reopen any discussions
If above doesn't address requirements motivated by some specific use case I would need to see that specific use case.
I think libraries can take care of DX. I don't see adding different way to accomplish the same thing that much helpful. Especially if it would rely on nuances (eg. Slug header), add extra burden on storage server implementations, and blurry expectations client applications can make about interactions with storage servers. |
|
Don't most of the reasons you'd want to POST and LDP-RS also apply to LDP-NRs?
|
In context of LDP,
POSTis used to add resources to containers ie.POSTto LDPC resource optionally using theSlugheader andLinkfor interaction model(s).What should be the
POSTbehaviour to target resources that are not LDPCs?If the target resource exist, what should happen?
If the target resource doesn't exist, what should happen?
What are the effects of interaction model(s) (LDPR and/or LDPC) used in request's
Linkheader?How should requests to create a resource with the LDP-NR interaction model get handled?
What are the effects without an interaction model?
The text was updated successfully, but these errors were encountered: