David et al,
This is interesting. I see where David is going and also why the terms are a point of discussion. I would point out that my impression is that where David is coming from is adding MQTT as a way to either update or notify that an update is available to an HTTP resource. What's a little awkward in my opinion is that those the terms "GET","PUT","PATCH" are generally understood to be server methods, whereas in this case they are telling a client how to act on the received MQTT payload. Effectively saying "You performed a GET(probably) on resource XXX, so subscribe to this topic, and act as a server that is processing a (GET|PUT|PATCH) when you receive a message."
When what it means is understood it's understandable. ;) I kind of tend towards Paul's suggestion, as it describes the payload of the message, rather than the processing method. There is however the notion that this idea is tied directly into HTTP, so it might make more sense to incorporate HTTP terminology, even if inverted between client and server.
I do like the idea very much, even though it basically duplicates the concept of retained messages, since it doesn't count on the MQTT server being the sole custodian of knowledge. Basically you'd have an MQTT server storing retained messages to a central store, an HTTP server accessing that store, and potentially an HTTP server processing updates to retained messages by updating the store, then publishing to the MQTT server. Pretty elegant, particularly in terms of clients that don't need updates to the resource in question.