Overloaded GET

GET has always suffered most with respect to being overloaded.

With SOAP, people 'GET' something over POST. But SOAP is not the only 'culprit' in overloading HTTP verbs and GET (or POST, whichever way you look at it) in particularly.

While people use GET to perform actions with side-effects, that is something which is not very interesting as there are often some obvious solutions available like using POST instead.

More interesting is how to GET the metadata for a given resource.
Dave Orchard writes in one of his latest posts :

One interesting aspect of the document is that it specifies how a web site can authorize other web sites to do non-GET operations such as PUT or DELETE. The client makes an authorization request by creating an HTTP GET with the http header Method-Check. The server then responds with an HTTP Response containing Access-Control HTTP Headers or even an XML document with Processing Instructions.
Now the part that I found very interesting is that it seems that the client's authorization request isn't really for the resource identified by the URI, because the goal is to actually get the authorization information. Thus, an HTTP GET has been over-ridden to be a GET of metadata about a resource. Also interestingly, if the URI for some reason doesn't know about the Method-Check header, then it will return the "wrong" representation, that is the actual representation. There is no way of requiring that the server knows about the Method-Check request.

Here's another example from a Waddling in Jersey post :

GET /resources/form/colours
Accept: application/vnd.sun.wadl+xml

returns a piece of metadata describing how to access this "/resources/form/colours" resource but not the actual state of this resource like {red, blue}.

I was explained recently how Rails approaches problems like this one.
The Rails way is to do

GET /resources/form/colours.wadl

or to get the access control data :

GET /resources/form/colours.acl

This approach is probably the least ambiguous but some care needs to be taken here to avoid clashes with actual custom resources, etc.

When HTTP headers are used to 'overload' GETs as in examples above, one issue, as noted by David, is that if a given resource does not recognize a header then a 'wrong' representation is returned. Using 'MustUnderstand' SOAP feature is indeed can be of interest in cases when a service node needs to either recognize a header or fail.