I can see the benefits in respecting request method semantics, but you can do that while using query strings, can't you? If someone calls http://example.com/?Bla.delete.1 with GET, you can just return 405 and do nothing.
I think that would technically fit the constraints, but it eliminates some of the benefits of the uniform interface if you have to POST to some URL instead of simply DELETEing the resource.
Again, you can have a URL like http://example.com?Articles.delete.1 and only accept DELETE requests. (However, I'm speaking about web applications, rather than services. This URL would be useless, since browsers don't support form-based DELETE and PUT for some reason. But that's beside the point.)
Point is, proper handling of GET, POST, PUT and DELETE is all about what you do when receiving those requests, not about the way you compose your URLs. At least that what it seems to be. If I'm wrong, I would very much like to hear why.
But you want to DELETE the actual article, not its deletion page ;) More specifically, if the client is reading an article in some URL, he shouldn't need to find out what's the special deletion URL. It leads to more brittle and less generic clients, with more work for the developer.
Point is, proper handling of GET, POST, PUT and DELETE is all about what you do when receiving those requests, not about the way you compose your URLs. At least that what it seems to be. If I'm wrong, I would very much like to hear why.
I think you're right if the goal is to abide by the REST constraints.
I see what you're saying about deleting the deletion page. It's an interesting point. Having separate URLs for GET, POST, PUT, DELETE, etc. on the same logical entity breaks the connection between those operations. However, I still don't see much added (practical) value in maintaining that connection, especially when it comes to websites (vs APIs). Even in perfect REST world, an article can be represented by a dozen URLs:
They might look different and only some of them might be DELETEable. (Or am I wrong here? I'm not entirely sure.) How that's different from treating http://example.com?Articles.delete.1 as a deletable representation of the same article? Both will affect many other pages on the website. You still need to understand what the request means to really know the consequences of sending it.
In short, I don't think there is anything particularly wrong with doing URLs the way I described.
