Mike,

With all due respect I find most of my conversations with you to usually lead to
no positive outcome, so I'd rather not enter yet another of those debates. Plus
Jan is already on it and I have little to add for now.

--
Sebastien Lambla


On 16 Dec 2011, at 08:40, "Mike Kelly" <mike@...> wrote:

> non·sense /ˈnänˌsens/
> Noun:Words that make no sense.
>
> "The fact that the guys that built Rails were implementing rest badly"
>
> 1. That is not a fact. It is your opinion.
> 2. The phrase 'implementing rest' makes no sense.
>
> Please just let it go and get back to the point, I asked you several
> legitimate questions.
>
> On Thu, Dec 15, 2011 at 11:37 PM, Sebastien Lambla <seb@...> wrote:
>> I tend to not dig into conversations that involve the word nonsense.
>>
>> --
>> Sebastien Lambla
>>
>>
>> On 15 Dec 2011, at 22:01, "Mike Kelly" <mike@...> wrote:
>>
>>> On Thu, Dec 15, 2011 at 8:36 PM, Sebastien Lambla <seb@...> wrote:
>>>> Mostly because the whole web works that way.
>>>
>>> Clearly, this is not true. Hence the topic of conversation.
>>>
>>>> The fact that the guys that built Rails were implementing rest badly (and
calling it restful routes or whatever)
>>>
>>> With respect, that is complete nonsense. Rails' routing DSL is
>>> actually extremely flexible, and significantly more sophisticated than
>>> most alternatives. What exactly are you trying to do with HTTP that
>>> you can't do with Rails?
>>>
>>>> won't be enough of a leverage to change the whole web. neither was it for
people that did non-safe operations on Get.
>>>
>>> That is not a sensible comparison:
>>>
>>> Using GET for non-safe operations is obviously wrong, as the benefit
>>> of GET being safe across the web is clear. On the other hand, the
>>> benefit to having guaranteed fullness of a PUT request across the web
>>> is _not at all clear_.
>>>
>>>> Eventually, people learn and use HTTP the way it's implemented out there
and stop breaking things and everybody lives happily after that.
>>>
>>> So what is the _actual concern_ you have about partial PUT that's
>>> preventing you from living happily ever after? What is it that's
>>> actually being broken?
>>>
>>>> As for "fixing" it, indeed there is nothing to be fixed, there's already
POST and PATCH, the stuff that needs fixing is rails.
>>>
>>> Neither of those fixes would actually work in practice - you can't
>>> just swap out partial PUT for POST or PATCH because neither of them
>>> are idempotent and therefore would require clients to remodel how they
>>> deal with failed requests.

On Fri, Dec 16, 2011 at 9:30 AM, Sebastien Lambla <seb@...> wrote:
> Mike,
>
> With all due respect I find most of my conversations with you to usually lead
to no positive outcome, so I'd rather not enter yet another of those debates.
Plus Jan is already on it and I have little to add for now.
>

That being the case, why did you bother announcing you were reluctant
based on my use of "nonsense"? .. yet more nonsense.

If you want 'positive outcomes', it's probably a good idea that you
don't present derogatory opinion about other people's hard work as
"fact". If you must do that and you get called on it then don't act
surprised, and at least have the decency to either back it up or
retract it.

Jan was already 'on it' before, and that didn't seem to bother you too
much - it looks a bit like you're just back-peddling.

Either answer the questions addressed to you, or stop replying.

I have stopped replying, not due to my lack of answers (I was willing to provide
more feedback on real-world implementation of PUT), but because of the general
tone those conversations always end up taking, and this one is no different from
the various ones that have been had before, all of them involving discussions
around changing existing standards or webarch and none of them leading, to my
knowledge, to any concrete proposed changes to those standards through the
appropriate mediums.

Either way, I'd suggest bringing your request for changes in the semantics of
PUT on the HTTP-bis mailing list, which is the correct forum to discuss changes
to the existing standard. For those not aware of it, see
http://wiki.tools.ietf.org/wg/httpbis/trac/wiki#Participate

Now I'll stop replying and go back to building things. Cheerios.

Seb

________________________________________
From: Mike Kelly [mike@...]
Sent: 16 December 2011 12:01
To: Sebastien Lambla
Cc: Jakob Strauch; rest-discuss@yahoogroups.com
Subject: Re: [rest-discuss] Re: Rails 3.2 and PATCH

On Fri, Dec 16, 2011 at 9:30 AM, Sebastien Lambla <seb@...> wrote:
> Mike,
>
> With all due respect I find most of my conversations with you to usually lead
to no positive outcome, so I'd rather not enter yet another of those debates.
Plus Jan is already on it and I have little to add for now.
>

That being the case, why did you bother announcing you were reluctant
based on my use of "nonsense"? .. yet more nonsense.

If you want 'positive outcomes', it's probably a good idea that you
don't present derogatory opinion about other people's hard work as
"fact". If you must do that and you get called on it then don't act
surprised, and at least have the decency to either back it up or
retract it.

Jan was already 'on it' before, and that didn't seem to bother you too
much - it looks a bit like you're just back-peddling.

Either answer the questions addressed to you, or stop replying.

On 2011-12-15 21:36, Sebastien Lambla wrote:
> Mostly because the whole web works that way. The fact that the guys that
> built Rails were implementing rest badly (and calling it restful routes
> or whatever) won't be enough of a leverage to change the whole web.
> neither was it for people that did non-safe operations on Get.
>
> Eventually, people learn and use HTTP the way it's implemented out there
> and stop breaking things and everybody lives happily after that.
>
> As for "fixing" it, indeed there is nothing to be fixed, there's already
> POST and PATCH, the stuff that needs fixing is rails.
> ...


That being said...

1) See <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/267>. The new
text in HTTPbis is:

".... Partial content updates are possible by targeting a separately
identified resource with state that overlaps a portion of the larger
resource, or by using a different method that has been specifically
defined for partial updates (for example, the PATCH method defined in
[RFC5789])."

2) Also: just replacing PUT with PATCH is not sufficient. The
Content-Type of the PATCH requests describes the patch format, not the
format being patched.

Best regards, Julian

Separately identified resource being the keyword here.

--
Sebastien Lambla


On 15 Dec 2011, at 22:03, "Julian Reschke" <julian.reschke@...> wrote:

> On 2011-12-15 21:36, Sebastien Lambla wrote:
>> Mostly because the whole web works that way. The fact that the guys that
>> built Rails were implementing rest badly (and calling it restful routes
>> or whatever) won't be enough of a leverage to change the whole web.
>> neither was it for people that did non-safe operations on Get.
>>
>> Eventually, people learn and use HTTP the way it's implemented out there
>> and stop breaking things and everybody lives happily after that.
>>
>> As for "fixing" it, indeed there is nothing to be fixed, there's already
>> POST and PATCH, the stuff that needs fixing is rails.
>> ...
>
>
> That being said...
>
> 1) See <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/267>. The new text
in HTTPbis is:
>
> ".... Partial content updates are possible by targeting a separately
identified resource with state that overlaps a portion of the larger resource,
or by using a different method that has been specifically defined for partial
updates (for example, the PATCH method defined in [RFC5789])."
>
> 2) Also: just replacing PUT with PATCH is not sufficient. The Content-Type of
the PATCH requests describes the patch format, not the format being patched.
>
> Best regards, Julian

On 2011-12-16 00:35, Sebastien Lambla wrote:
> Separately identified resource being the keyword here.

"using a different method that has been specifically defined for partial
updates" being the other.

> --
> Sebastien Lambla
>
> On 15 Dec 2011, at 22:03, "Julian Reschke" <julian.reschke@...
> <mailto:julian.reschke%40gmx.de>> wrote:
>
>  > On 2011-12-15 21:36, Sebastien Lambla wrote:
>  >> Mostly because the whole web works that way. The fact that the guys that
>  >> built Rails were implementing rest badly (and calling it restful routes
>  >> or whatever) won't be enough of a leverage to change the whole web.
>  >> neither was it for people that did non-safe operations on Get.
>  >>
>  >> Eventually, people learn and use HTTP the way it's implemented out there
>  >> and stop breaking things and everybody lives happily after that.
>  >>
>  >> As for "fixing" it, indeed there is nothing to be fixed, there's already
>  >> POST and PATCH, the stuff that needs fixing is rails.
>  >> ...
>  >
>  >
>  > That being said...
>  >
>  > 1) See <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/267>. The
> new text in HTTPbis is:
>  >
>  > ".... Partial content updates are possible by targeting a separately
> identified resource with state that overlaps a portion of the larger
> resource, or by using a different method that has been specifically
> defined for partial updates (for example, the PATCH method defined in
> [RFC5789])."
>  >
>  > 2) Also: just replacing PUT with PATCH is not sufficient. The
> Content-Type of the PATCH requests describes the patch format, not the
> format being patched.
>  >
>  > Best regards, Julian
>
>

On Dec 15, 2011, at 2:02 AM, Mike Kelly wrote:

> On Thu, Dec 15, 2011 at 9:14 AM, Jan Algermissen
> <jan.algermissen@...> wrote:
>>
>> On Dec 15, 2011, at 1:42 AM, Mike Kelly wrote:
>>
>>> I created a question on Stack Overflow about this a while ago:
>>>
>>>
http://stackoverflow.com/questions/2364110/whats-the-justification-behind-disall\
owing-partial-put
>>>
>>> I still don't really understand the benefit of not allowing PUT to be
>>> partial,
>>
>> So you are asking, why PUT was defined as idempotent in the first place, yes?
>>
>> I think the reason is sort of "because we can define it that way". There is
POST, which has no visibility (==POST is meaningless to an intermediary) and
everything could just be done with POST. But then, adding methods that *have*
visibility adds some serious capabilities to HTTP. E.g. GET's semantics allow
for caching and it is also very helpful that we know that GET is safe - we can
call it any number of times.
>>
>
> .. and PUTs 'complete replace' semantics allow for.. ?

The ability to write patch representations onto a server so that those
patches can later be retrieved by others.

....Roy

On Mon, Dec 19, 2011 at 12:16 AM, Roy T. Fielding <fielding@...> wrote:
> On Dec 15, 2011, at 2:02 AM, Mike Kelly wrote:
>
>> On Thu, Dec 15, 2011 at 9:14 AM, Jan Algermissen
>> <jan.algermissen@...> wrote:
>>>
>>> On Dec 15, 2011, at 1:42 AM, Mike Kelly wrote:
>>>
>>>> I created a question on Stack Overflow about this a while ago:
>>>>
>>>>
http://stackoverflow.com/questions/2364110/whats-the-justification-behind-disall\
owing-partial-put
>>>>
>>>> I still don't really understand the benefit of not allowing PUT to be
>>>> partial,
>>>
>>> So you are asking, why PUT was defined as idempotent in the first place,
yes?
>>>
>>> I think the reason is sort of "because we can define it that way". There is
POST, which has no visibility (==POST is meaningless to an intermediary) and
everything could just be done with POST. But then, adding methods that *have*
visibility adds some serious capabilities to HTTP. E.g. GET's semantics allow
for caching and it is also very helpful that we know that GET is safe - we can
call it any number of times.
>>>
>>
>> .. and PUTs 'complete replace' semantics allow for.. ?
>
> The ability to write patch representations onto a server so that those
> patches can later be retrieved by others.
>

No, that's already made able by virtue of PUT being an 'update',
right? I was asking specifically about httpbis' overspecified:

'PUT is an idempotent update of state that is a complete replacement'

vs the more generally applicable and succinct:

'PUT is an idempotent update of state'

Both of those allow for the ability to write patch representations
onto a server so that those patches can later be retrieved by others.
What does the former benefit the web that the latter does not?

Afaict, the former actually prevents a set of uses for PUT (and
therefore w/ HTTP as a whole) that would be possible under the latter.
So it's not only less succinct, it's also restrictive too.

Cheers,
Mike

> 'PUT is an idempotent update of state'

No, PUT is 'a request that an entity be stored at a location. This
entity is considered the most current version.'

> What does the former benefit the web that the latter does not?

Dealing with whole updates has many, many less edge cases, for
one...for a certain definition of 'simple,' it's much simpler.

On Dec 19, 2011, at 3:00 AM, Mike Kelly wrote:

> On Mon, Dec 19, 2011 at 12:16 AM, Roy T. Fielding <fielding@...> wrote:
>> On Dec 15, 2011, at 2:02 AM, Mike Kelly wrote:
>>> .. and PUTs 'complete replace' semantics allow for.. ?
>>
>> The ability to write patch representations onto a server so that those
>> patches can later be retrieved by others.
>>
>
> No, that's already made able by virtue of PUT being an 'update',
> right?

No, if the update looks like a patch and PUT is allowed to perform
patch semantics then the server will attempt to perform those semantics
and fail to store the patch.  Likewise, if the client expects a partial
update to work with PUT and sends that message to an HTTP server that
doesn't implement partial PUTs (i.e., all of them), then the current
representation will be entirely replaced with the partial content
regardless of your opinion on how PUT might be specified otherwise.

> I was asking specifically about httpbis' overspecified:
>
> 'PUT is an idempotent update of state that is a complete replacement'
>
> vs the more generally applicable and succinct:
>
> 'PUT is an idempotent update of state'

And you have been answered, many times.  PUT means PUT.  There are no
partial updates in PUT.  There was a half-assed attempt to add those
semantics by committee in the midst of standardizing HTTP, but that
attempt failed because PUT's existing semantics had already been deployed
and we can't graft partial updates on top of existing replace semantics.
Period.  End of story.  Hence, PATCH was defined in 1995 (and finally
standardized much later because the WebDAV group was lazy).

This answer is final.  If anyone implements it differently in Rails,
then Rails will be neither compliant with HTTP nor compliant with REST.
Whether that matters to anyone developing Rails is besides the point.

....Roy

On Mon, Dec 19, 2011 at 12:32 PM, Roy T. Fielding <fielding@...> wrote:
> On Dec 19, 2011, at 3:00 AM, Mike Kelly wrote:
>
>> On Mon, Dec 19, 2011 at 12:16 AM, Roy T. Fielding <fielding@...> wrote:
>>> On Dec 15, 2011, at 2:02 AM, Mike Kelly wrote:
>>>> .. and PUTs 'complete replace' semantics allow for.. ?
>>>
>>> The ability to write patch representations onto a server so that those
>>> patches can later be retrieved by others.
>>>
>>
>> No, that's already made able by virtue of PUT being an 'update',
>> right?
>
> No, if the update looks like a patch and PUT is allowed to perform
> patch semantics then the server will attempt to perform those semantics
> and fail to store the patch.  Likewise, if the client expects a partial
> update to work with PUT and sends that message to an HTTP server that
> doesn't implement partial PUTs (i.e., all of them)

It's not all of them though, is it? 2616 is nowhere near clear about
this.. if it was, why would there have been a requirement you to try
and "clarify" it?

> then the current
> representation will be entirely replaced with the partial content
> regardless of your opinion on how PUT might be specified otherwise.

So your argument is based on the premise that clients go around PUTing
representations to servers willy-nilly with no application semantics
understood up front whatsoever? I have not seen anything in practice
which supports that premise.

>> I was asking specifically about httpbis' overspecified:
>>
>> 'PUT is an idempotent update of state that is a complete replacement'
>>
>> vs the more generally applicable and succinct:
>>
>> 'PUT is an idempotent update of state'
>
> And you have been answered, many times.  PUT means PUT.  There are no
> partial updates in PUT.

Sorry, that's much of an answer.

> There was a half-assed attempt to add those
> semantics by committee in the midst of standardizing HTTP, but that
> attempt failed because PUT's existing semantics had already been deployed
> and we can't graft partial updates on top of existing replace semantics.
> Period.  End of story.

Again; you must be aware that 2616 is not clear enough on this front,
otherwise why did you work on clarifying it?

Furthermore, there is no evidence - as in zero - of intermediary
mechanisms/plumbing that relies on PUT having replace semantics. I
have asked for an example several times in this thread. So there is
absolutely no evidence that changing this semantic would *actually*
have a detrimental effect on any web infrastructure. Specific
applications and their use of PUT would not be negatively effected by
generalising PUTs definition; the only requirement would be that those
applications take on the responsbility of specifying their additional
replace-only semantics for PUT in their context. Most applications do
this anyway, for example:

http://wiki.basho.com/Keys-and-Objects.html

"When performing any fetch or update operation in Riak, the entire
Riak Object must be retrieved or modified; there are no partial
fetches or updates."

> Hence, PATCH was defined in 1995 (and finally
> standardized much later because the WebDAV group was lazy).
>
> This answer is final.  If anyone implements it differently in Rails,
> then Rails will be neither compliant with HTTP nor compliant with REST.
> Whether that matters to anyone developing Rails is besides the point.

Well as it stands I don't think 2616 is anywhere clear enough for that
be an objective truth. Granted, this will become a truth if HTTPbis
pushes out its current over-specified interpretation of PUT - I would
contend that this is an unnecessary change for the worse, but given
your advantageous position; if you want to insist "that's just the way
it's going to be", there's not a lot I can do about it, is there? :)

Cheers,
Mike

On Dec 19, 2011, at 2:08 PM, Mike Kelly wrote:

> It's not all of them though, is it? 2616 is nowhere near clear about
> this.. if it was, why would there have been a requirement you to try
> and "clarify" it?

Ermm... , don't you think that Roy is sort of an authoritative source regarding
the question of what the authors of 2616 had in mind when they wrote it?

Jan

On Mon, Dec 19, 2011 at 2:05 PM, Jan Algermissen
<jan.algermissen@...> wrote:
>
> On Dec 19, 2011, at 2:08 PM, Mike Kelly wrote:
>
>> It's not all of them though, is it? 2616 is nowhere near clear about
>> this.. if it was, why would there have been a requirement you to try
>> and "clarify" it?
>
> Ermm... , don't you think that Roy is sort of an authoritative source
regarding the question of what the authors of 2616 had in mind when they wrote
it?
>

Probably. What does that have to do with whether the resulting
specification was actually clear or not?

On 2011-12-19 13:32, Roy T. Fielding wrote:
> ...
> Period. End of story. Hence, PATCH was defined in 1995 (and finally
> standardized much later because the WebDAV group was lazy).
> ...

What exactly does this have to do with WebDAV? Do you think WebDAV
should have defined PATCH?

Best regards, Julian

On Dec 19, 2011, at 6:05 AM, Julian Reschke wrote:

> On 2011-12-19 13:32, Roy T. Fielding wrote:
>> ...
>> Period. End of story. Hence, PATCH was defined in 1995 (and finally
>> standardized much later because the WebDAV group was lazy).
>> ...
>
> What exactly does this have to do with WebDAV? Do you think WebDAV should have
defined PATCH?

Yes, it was part of the original authoring task when the DAV WG was initiated.
That's why I removed PATCH from RFC2068 (because it was supposedly going to
be developed further by DAV and we did not want a conflicting definition).

....Roy

--- In rest-discuss@yahoogroups.com, Mike Kelly <mike@...> wrote:
>
> I created a question on Stack Overflow about this a while ago:
>
>
http://stackoverflow.com/questions/2364110/whats-the-justification-behind-disall\
owing-partial-put
>
> I still don't really understand the benefit of not allowing PUT to be
> partial

If you allow that, how would a server be able to determine the nature of the
update (partial or complete) and perform its job?

For example, suppose that PUT was allowed to be partial:

----------------
GET /mydog

200 OK

<dog>
     <status>happy</status>
     <favoriteToy>A red muppet</favoriteToy>
</dog>
----------------

Then:

----------------
PUT /mydog

<dog>
     <status>sleepy</status>
</dog>
----------------

Am I doing a partial update (just changing my dog's status), or a complete one
(changing his status and removing an optional "favoriteToy" information) ?

Philippe

Your application can specify whether or not the request is intended as
a complete update or not.

If the application does specify it as complete then omission is
removal, if it doesn't then the deletable sections would have to be
given their own URI to receive a DELETE. I find it's much easier to
establish deletable sections than updatable partials up front, as
deletes are generally determined by the application needs whereas
partial updates are determined by client needs (which are often
unknowable when designing the application).

Cheers,
Mike

On Sat, Dec 17, 2011 at 5:15 PM, Philippe Mougin <pmougin@...> wrote:
>
>
> --- In rest-discuss@yahoogroups.com, Mike Kelly <mike@...> wrote:
>>
>> I created a question on Stack Overflow about this a while ago:
>>
>>
http://stackoverflow.com/questions/2364110/whats-the-justification-behind-disall\
owing-partial-put
>>
>> I still don't really understand the benefit of not allowing PUT to be
>> partial
>
> If you allow that, how would a server be able to determine the nature of the
update (partial or complete) and perform its job?
>
> For example, suppose that PUT was allowed to be partial:
>
> ----------------
> GET /mydog
>
> 200 OK
>
> <dog>
>    <status>happy</status>
>    <favoriteToy>A red muppet</favoriteToy>
> </dog>
> ----------------
>
> Then:
>
> ----------------
> PUT /mydog
>
> <dog>
>    <status>sleepy</status>
> </dog>
> ----------------
>
> Am I doing a partial update (just changing my dog's status), or a complete one
(changing his status and removing an optional "favoriteToy" information) ?
>
> Philippe
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

On Dec 17, 2011, at 6:59 PM, Mike Kelly wrote:

> Your application can specify whether or not the request is intended as
> a complete update or not.

What happened to the uniform interface constraint?

Jan

Nothing, the uniform interface of HTTP simply becomes less constrained
with regard to PUT. PUT's semantics are simplified, and the change
adds a useful capability that is lacking in HTTP's interface (i.e.
partial idempotent updates).

Reducing the semantics of PUT to be agnostic about fullness, retains
visibility of request in terms of being idempotent,
updating/instating, and non-safe. It drops visibility in terms of
being able to determine partial/fullness of the request - and offloads
this to shared understanding between client and server via standard
media types, link relations or application documentation.

They key here is that the drop in visibility does not appear to
disrupt any existing or proposed web infrastructure, but it does
enable a specific client/server interaction which would otherwise be
impossible (idempotent partial updates). It would also reduce the
complexity of PUT's semantics because it would remove the need to
specify any of the additional semantics in place with regard to 'full
replacement'.

Cheers,
Mike

On Sat, Dec 17, 2011 at 6:30 PM, Jan Algermissen
<jan.algermissen@...> wrote:
>
> On Dec 17, 2011, at 6:59 PM, Mike Kelly wrote:
>
>> Your application can specify whether or not the request is intended as
>> a complete update or not.
>
> What happened to the uniform interface constraint?
>
> Jan
>

On Sat, Dec 17, 2011 at 9:01 PM, Erik Mogensen <erik@...> wrote:
> On Sat, Dec 17, 2011 at 8:39 PM, Mike Kelly <mike@...> wrote:
>>
>> Reducing the semantics of PUT to be agnostic about fullness, retains
>> visibility of request in terms of being idempotent,
>> updating/instating, and non-safe. It drops visibility in terms of
>> being able to determine partial/fullness of the request - and offloads
>> this to shared understanding between client and server via standard
>> media types, link relations or application documentation.
>>
> Let's, for the sake of argument assume that idempotent updates are OK, and
> that PUT has been overloaded with this capability.
>
> How would an origin server know to use replace or update semantics?
>
> Would it be determined based on the Content-Type?  e.g. text/plain,
> application/atom+xml are "full update" media types whereas, say, a
> hypothetical text/idempotent-patch is not?
>
> I would find it really odd if the following were true:
> "If you PUT a text/plain to me, I will store it"
> "if you PUT a text/idempotentpatch to me, I will apply the patch"
>
> It would also fall apart if I e.g. wanted to create a resource which had
> only one representation, that of said text/idempotentpatch media type. What
> would a PUT method mean? Replace the representation of the
> text/idempotentpatch, or apply it?
>
> What does a PUT with a partial update of a resource that does not exist
> mean?  Store the "partial update" document at the URI?  Or return 404 (since
> there's nothing to apply)?

Those are all questions for whoever is designing and specifying the
application/API in question, given resources will behave in the way
that the application that governs them specifies. Why does HTTP need
to get involved at that level?

Cheers,
Mike

On 2011-12-14 23:40, Steve Klabnik wrote:
> Hey everyone!
>
> I just wanted to draw attention to the discussion here:
> https://github.com/rails/rails/pull/505
>
> While the pull request is originally from May, there's some discussion
> about adding support for PATCH in Rails 3.2. If you read the
> discussion, there's a lot of controversy over the semantics of PUT and
> partial updates, discussion about if and when PATCH will become more
> than a draft standard, and all kinds of fun stuff.
> ...

PATCH will never become a "draft" standard, as the IETF just got rid of
this standards level.

PUT, defined in RFC 2616 and being revised in HTTPbis, will go back to
"Proposed", soon, btw. (*)

Best regards, Julian

PS: because "Draft" is gone, and we can't go to "full standard" given
the amount of changes we're making.

On Thu, Dec 15, 2011 at 16:16, Julian Reschke <julian.reschke@...> wrote:
> On 2011-12-14 23:40, Steve Klabnik wrote:
>> Hey everyone!
>>
>> I just wanted to draw attention to the discussion here:
>> https://github.com/rails/rails/pull/505
>>
>> While the pull request is originally from May, there's some discussion
>> about adding support for PATCH in Rails 3.2. If you read the
>> discussion, there's a lot of controversy over the semantics of PUT and
>> partial updates, discussion about if and when PATCH will become more
>> than a draft standard, and all kinds of fun stuff.
>> ...
>
> PATCH will never become a "draft" standard, as the IETF just got rid of
> this standards level.
>
> PUT, defined in RFC 2616 and being revised in HTTPbis, will go back to
> "Proposed", soon, btw. (*)
>
> Best regards, Julian
>
> PS: because "Draft" is gone, and we can't go to "full standard" given
> the amount of changes we're making.
>

RFOL

I thought PATCH is already standardized!?
See http://tools.ietf.org/html/rfc5789

The other thing that confuses me now is what advantages has the PATCH method
compared to POST? Both are neither safe nor idempotent. In regard to POST
the above RFC just says that "POST is already used but without broad
interoperability (for one, there is no standard way to discover patch format
support).


--
Markus Lanthaler
@markuslanthaler

On 2011-12-15 19:21 , Markus Lanthaler wrote:
> The other thing that confuses me now is what advantages has the PATCH method
> compared to POST? Both are neither safe nor idempotent. In regard to POST
> the above RFC just says that "POST is already used but without broad
> interoperability (for one, there is no standard way to discover patch format
> support).

that's pretty much it, afaict. the PATCH media type is the diff format,
and not the media type of the resources involved. so you could make
explicit that you are, for example, using a specific XML diff format (if
any of those ever bothered to register a media type...), and peers could
negotiate which formats they expect and support.

cheers,

dret.

On Dec 16, 2011, at 4:24 AM, Erik Wilde wrote:

> On 2011-12-15 19:21 , Markus Lanthaler wrote:
> > The other thing that confuses me now is what advantages has the PATCH method
> > compared to POST? Both are neither safe nor idempotent. In regard to POST
> > the above RFC just says that "POST is already used but without broad
> > interoperability (for one, there is no standard way to discover patch format
> > support).
>
> that's pretty much it, afaict. the PATCH media type is the diff format,
> and not the media type of the resources involved. so you could make
> explicit that you are, for example, using a specific XML diff format (if
> any of those ever bothered to register a media type...), and peers could
> negotiate which formats they expect and support.

From the spec at http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6 :

"The fundamental difference between the POST and PUT requests is reflected in
the different meaning of the Request-URI....".

PATCH vs POST is similar, with e.g. the consequence that the additional
visibility of PATCH allows caches to mark copies of a resource as stale if a
PATCH to them succeeded.

Jan





>
> cheers,
>
> dret.
>

On 2011-12-16 04:21, Markus Lanthaler wrote:
> I thought PATCH is already standardized!?
> See http://tools.ietf.org/html/rfc5789

Yes. But the IETF has different standardization levels.

> ...

Best regards, Julian

I'm not sure I understand what you mean. Could you please elaborate a bit on
this?

Thanks,
Markus



> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@...]
> Sent: Friday, December 16, 2011 5:16 PM
> To: Markus Lanthaler
> Cc: rest-discuss@yahoogroups.com
> Subject: Re: [rest-discuss] Rails 3.2 and PATCH
>
> On 2011-12-16 04:21, Markus Lanthaler wrote:
> > I thought PATCH is already standardized!?
> > See http://tools.ietf.org/html/rfc5789
>
> Yes. But the IETF has different standardization levels.
>
> > ...
>
> Best regards, Julian

On 2011-12-17 12:55, Markus Lanthaler wrote:
> I'm not sure I understand what you mean. Could you please elaborate a bit on
> this?
> ...

Not every RFC is on the IETF Standards Track, and RFCs which are on the
Standards Track can be at different maturity levels (for a long time 3,
now 2).

Some people argued that PATCH is somehow "less" standardized than PUT
because it's currently a "Proposed" standard only.

Of course that's BS; most of the internet runs on proposed standards.

Best regards, Julian