> Ah, now I see the crux of the problem: you've mixed up safety and idempotency.
That's not the miscommunication here. The reason I mentioned state mutation was only to clarify that the RFC does not dictate consistent internal server state. Even a "safe" call is only considered safe from the view of the caller. It also does not "warn developers" against changing state as a side effect of a "safe" call. It specifically states that this may be considered a feature, but that the user does not request any such side effects. Again, the concentration here is on the behavior of the communications, and not on the internal behavior of the server.
> But the final proof that idempotency is not with respect to communications comes from the spec itself: RFC 2616, section 9.1.2, first sentence. The spec even explicitly states that error or expiration issues can cause different responses on subsequent requests, which is what makes it clear that idempotency is not with respect to communications.
We're clearly reading this RFC differently. I see the error and expirations as being server-side. X expired? Sure, "GET X" will return a different result. Disk failed (aka error), certainly the response is going to change.
The RFC calls out changing the behavior in response to errors or expirations as an exception to idempotent behavior. I see this as confirmation that the server should behave consistency from the perspective of the caller except in cases where this is not possible.
> "Not Found" is an error condition with respect to the server. That is a fact of the HTTP server specification
I don't agree that "Not Found" is an error condition for delete. This is not in the spec. It's your interpretation of the spec. Nowhere in the RFC does it say "if a request comes in for X and X does not exist, a 400-level error should be returned". (If it did say that, PUT would be quite useless.)
> Actually, the RFC doesn't say that. The relevant section (9.7) states that DELETE is for actual requests to delete something. Nothing else. To "make sure nothing exists at a URL", the proper method is GET. You can also use HEAD if you're worried about a large entity-body taking up too much bandwidth. OPTIONS would work too, and it has the advantage of only touching the metadata, but not all servers support it.
You misunderstood what I was saying. "Make sure nothing exists" isn't an intention. It's a command. It's "Hey, server, make sure that when you return, nothing exists at location X." It's a delete, but a less "strict" version than yours, which is "Hey, go find out if something exists at X, remove it if so, and throw an error otherwise."
I don't think we're getting any closer to agreeing on this. I looked for a more definitive answer from one of the RFC authors, but couldn't find anything. It's just this same discussion playing out over and over with other people.
That's not the miscommunication here. The reason I mentioned state mutation was only to clarify that the RFC does not dictate consistent internal server state. Even a "safe" call is only considered safe from the view of the caller. It also does not "warn developers" against changing state as a side effect of a "safe" call. It specifically states that this may be considered a feature, but that the user does not request any such side effects. Again, the concentration here is on the behavior of the communications, and not on the internal behavior of the server.
> But the final proof that idempotency is not with respect to communications comes from the spec itself: RFC 2616, section 9.1.2, first sentence. The spec even explicitly states that error or expiration issues can cause different responses on subsequent requests, which is what makes it clear that idempotency is not with respect to communications.
We're clearly reading this RFC differently. I see the error and expirations as being server-side. X expired? Sure, "GET X" will return a different result. Disk failed (aka error), certainly the response is going to change.
The RFC calls out changing the behavior in response to errors or expirations as an exception to idempotent behavior. I see this as confirmation that the server should behave consistency from the perspective of the caller except in cases where this is not possible.
> "Not Found" is an error condition with respect to the server. That is a fact of the HTTP server specification
I don't agree that "Not Found" is an error condition for delete. This is not in the spec. It's your interpretation of the spec. Nowhere in the RFC does it say "if a request comes in for X and X does not exist, a 400-level error should be returned". (If it did say that, PUT would be quite useless.)
> Actually, the RFC doesn't say that. The relevant section (9.7) states that DELETE is for actual requests to delete something. Nothing else. To "make sure nothing exists at a URL", the proper method is GET. You can also use HEAD if you're worried about a large entity-body taking up too much bandwidth. OPTIONS would work too, and it has the advantage of only touching the metadata, but not all servers support it.
You misunderstood what I was saying. "Make sure nothing exists" isn't an intention. It's a command. It's "Hey, server, make sure that when you return, nothing exists at location X." It's a delete, but a less "strict" version than yours, which is "Hey, go find out if something exists at X, remove it if so, and throw an error otherwise."
I don't think we're getting any closer to agreeing on this. I looked for a more definitive answer from one of the RFC authors, but couldn't find anything. It's just this same discussion playing out over and over with other people.