- From: John Arwe <johnarwe@us.ibm.com>
- Date: Fri, 7 Jun 2013 15:50:20 -0400
- To: public-ldp-wg@w3.org
- Message-ID: <OF95F62412.1366C1DB-ON85257B83.006B0CAE-85257B83.006CFC99@us.ibm.com>
Related-but-distinct point #1: Creates can be done via means other that POST. Both PUT and PATCH allow creates explicitly; we discourage PATCH as create IIRC, but we're more neutral on PUT in part due to discussions at F2F1. When I made the proposal for a new header scoped specifically to POST-for-create, I did that intentionally. The HTTP-defined semantics of PUT and PATCH are more constrained than POST; I think in both cases the worst-case "penalty" a client intending a create-only pays is making a prospective HEAD request on the "new resource"'s URI; if it receives a 404, the semantics it should anticipate are clear (create) although this is never guaranteed due to race conditions. Simpler still is to make the request conditional (If-None-Match: *). Thus, I don't see any need to add to "what is" for create via PUT/PATCH. HTTP as it is appears to be sufficient. This might be worth pointing out in Deployment. Related-but-distinct point #2: looking across the Methods that LDP uses, how does a client know which media types are supported? For responses, HTTP Accept should suffice. Knowledge that the client is interacting with an LDP Server constrains that a bit further (MUST offer Turtle for LDPRs, etc). For requests, we have (by method) a. HEAD: n/a (no request/response payload) b. POST: Accept-Post-Create proposal in issue-80 covers LDP’s needs c. GET: n/a (no request payload) d. PUT: rely on conneg; nothing prospective; most servers will probably accept "any" format they serve e. PATCH: Accept- Patch already covers the need I realize there are edge cases (PUT back updated HTML for an LDPR may be non-sensical unless it's "special" HTML with RDFa/etc), this is just the broad-brush version to see if it prompts any needed discussion. Unless we feel a need for an "Accept-Put" analog ... and I don't think LDP is intentionally trying to encourage PUTs that much... that state might be fine. Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario
Received on Friday, 7 June 2013 19:50:54 UTC