Re: Issue-80: Post media types usable for Create; background for proposal

> >"hints" are of dubious value to implementations.  If you act like you
> you may have some misunderstanding here. hints are just optimizations. 
for

I think it's just a matter of where you're standing.  If you're writing 
code, you're in one of the cases I articulated.  That's the sense in which 
I meant they're of dubious value - they don't save the implementer from 
*writing* any code, unless the hint is taken as a trusted assertion.  It's 
still possible to avoid *running* that code, or short-circuiting some 
actions, and come out a net winner. 

> there is no difference. POST and PATCH allow you to interact with a
> resource, and you typically send some media type representation in the
> request. the representation indicates what you want to do, for PATCH it

I think there is a very important difference that has butkus to do with 
media types.  2616 defines POST to have wide open semantics; the 
request-URI receives a set of processing instructions, with no further 
semantic restrictions.  POST can literally do anything, to any resource, 
without invoking the 'side effects' clause, given any media type as input.

5789 defines PATCH to modify (perhaps create) the resource given by the 
request-URI, given the patch document, which is a set of processing 
instructions *for modifying the resource identified by the request-URI* 
(not for anything you want, as post does).  5789 (erratum from Mark, 
below) goes so far as to say that servers should reject generic media type 
patch documents, since those media type registrations do not define their 
behavior wrt PATCH.

In LDP we are only intending to "allocate" the Create semantic of POST, of 
all the potential semantics that POST can be used for.  Being careful to 
only squat on the semantic we need is the one and only reason I was 
willing to add -Create on the proposed header.



2616 POST
9.5 POST


   The POST method is used to request that the origin server accept the
   entity enclosed in the request as a new subordinate of the resource
   identified by the Request-URI in the Request-Line. POST is designed
   to allow a uniform method to cover the following functions:

      - Annotation of existing resources;

      - Posting a message to a bulletin board, newsgroup, mailing list,
        or similar group of articles;

      - Providing a block of data, such as the result of submitting a
        form, to a data-handling process;

      - Extending a database through an append operation.

   The actual function performed by the POST method is determined by the
   server and is usually dependent on the Request-URI. The posted entity
   is subordinate to that URI in the same way that a file is subordinate
   to a directory containing it, a news article is subordinate to a
   newsgroup to which it is posted, or a record is subordinate to a
   database.


bis for POST:
   The POST method requests that the target resource process the
   representation enclosed in the request according to the resource's
   own specific semantics.  For example, POST is used for the following
   functions (among others):

   o  Providing a block of data, such as the fields entered into an HTML
      form, to a data-handling process;

   o  Posting a message to a bulletin board, newsgroup, mailing list,
      blog, or similar group of articles;

   o  Creating a new resource that has yet to be identified by the
      origin server; and

   o  Appending data to a resource's existing representation(s).

   An origin server indicates response semantics by choosing an
   appropriate status code depending on the result of processing the
   POST request; almost all of the status codes defined by this


5789 PATCH:
  This specification defines the new HTTP/1.1 [RFC2616] method, PATCH,
   which is used to apply partial modifications to a resource.
...
   The PATCH method requests that a set of changes described in the
   request entity be applied to the resource identified by the Request-
   URI.  The set of changes is represented in a format called a "patch
   document" identified by a media type.  If the Request-URI does not
   point to an existing resource, the server MAY create a new resource,

RFC5789, "PATCH Method for HTTP", March 2010
Source of RFC: IETF - NON WORKING GROUP
Errata ID: 3169

Status: Verified
Type: Technical

Reported By: Mark Nottingham
Date Reported: 2012-03-28
Verifier Name: Pete Resnick
Date Verified: 2012-03-29
Section 2 says: 
   If
   the operation does not modify the resource identified by the Request-
   URI in a predictable way, POST should be considered instead of PATCH
   or PUT.


It should say:
   If
   the operation does not modify the resource identified by the Request-
   URI in a predictable way that's defined by the semantics of the PATCH 
   media type, POST should be considered instead of PATCH or PUT.


[Also, I suggest adding this to section two, after the sixth paragraph:]

   The means of applying a PATCH request to a resource's state is
   determined by the request's media type.  If a server receives a PATCH
   request with a media type whose specification does not define
   semantics specific to PATCH, the server SHOULD reject the request by
   returning the 415 Unsupported Media Type status code, unless a more
   specific error status code takes priority.

   In particular, servers SHOULD NOT assume PATCH semantics for generic
   media types that don't define them, such as "application/xml" or
   "application/json".  Doing so will cause interoperability issues,
   because the semantics of PATCH become specific to that resource,
   rather than general.

Notes:
RFC5789 does not explicitly tie PATCHing semantics to the media type of 
the request. This was well understood in the discussions around the 
document, and can be read between the lines in it, but it doesn't come out 
and say it. 


Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario