Hacker News Reader

Comment by krick | Hacker News Reader

Is it really safe and reliable? Are there any situations when I should NOT add my custom verb whenever I please?

Yes, of course there are situations when you shouldn't use a custom verb.

- Routes that intended for use by people via clickable links (web browsers and email clients) obviously must use GET; I believe HTML forms are likewise limited to GET and POST by the `method` attribute (I've never submitted a PATCH form myself).

- You may have to interop with intermediate proxies that perform some form of DPI. For example, some proxies know that certain requests can be cached based on a URI. These proxies may not have support for custom verbs.

- Corporate firewalls may whitelist verbs [1].

In general, the idea is to strive to use verbs that have broad applicability in your API, but that doesn't mean every resource must implement every verb (e.g. read-only collections usually don't implement DELETE). But that's just an standard application of the uniform access principle.

[1] http://www.hanselman.com/blog/HTTPPUTOrDELETENotAllowedUseXH...

That sounds like a recipe for heartburn later, when you run into some WAF or whatever that only allows PUT/GET/DELETE/POST.

The cockroach that you see is usually not the only one around.

A framework that doesn't support extensible verbs in 2014 is bound to have more problems than just a failure to implement one RFC correctly.

He's not talking about a framework, he's talking about web application firewalls that only support the default verbs. It's quite common and has nothing to do with which framework you use.

Thanks for clearing that up, yes, as I've said, you should not use custom verbs if you have to interop with firewalls or proxy caches that perform DPI unless you've tested them.

Problem is that you may test the system now and it all works fine. But the day after you deploy, somebody named Murphy adds or updates a proxy somewhere in your topology that breaks things. Or your organization gets a new customer or partner with a differently configured network.

That's an argument for never doing anything.

Its an argument for being conservative in your design philosophy.

> The cockroach that you see is usually not the only one around.

Precisely, in a way.

Your request may go through proxy servers that do not recognize these verbs. Or users of your API may be stuck with an outdated framework that simply doesn't allow them.

Keep things sane and stick to GET/POST/PUT/DELETE.

I worked for a company once that only allowed GET/POST, they filtered PUT/DELETE at the proxy level.

You can't win. Do what is right, and then scale back to what the circumstances allow.

Reply on news.ycombinator.com