[dragonwriter]

> Using non-HTTP verbs (i.e. REPORT, SEARCH):

These are HTTP extensions, and are as much HTTP verbs as PATCH. The big problem is that REPORT and SEARCH are WebDAV extensions to HTTP, and their specs have WebDAV related baggage, and its at least as much "bad REST" to redefine the semantics of methods with existing standards as to use POST to get around the technical/practical problems with GET.

[vwelling]

Let me clarify, by non-HTTP I mean "not defined in the HTTP/1.1: Semantics and Content RFC" (RFC7231) and therefor not likely to be commonly implemented.

Could you elaborate on what you consider to be "bad REST" with regards to using POST in this case? The RFC clearly leaves the definition of the semantics of POST up to the implementation of that particular resource.

The only argument I could come up with, is that POST is not guaranteed to be idempotent or safe, whereas a search query would be. But a lack of guarantee doesn't exclude use cases where it would be.

[dragonwriter]

> Could you elaborate on what you consider to be "bad REST" with regards to using POST in this case?

I'm not saying POST is bad REST, I am acknowledging the claim by some that it is and, without debating whether or not it is, saying that using REPORT or SEARCH, as currently defined, is at least as bad as using POST from a REST point-of-view.

(I actually think that, in terms of using HTTP in a RESTful way, POST is the least-bad choice in terms of existing verbs, though it is not an exceptionally good fit -- its basically a case where POST-works-for-anything-for-which-no-other-method-seems-appropriate logic applies.)

[vwelling]

Ah, my bad, I misunderstood. Thanks for clarifying!