Hacker News Reader

Comment by politician | Hacker News Reader

You know that the verb mechanism is extensible, right?

If your API could benefit from a particular verb (SEARCH, MOVE, CHECKOUT), just use it. You don't need (more) permission from (another) RFC - RFC 2616 and 7231 [1] already gave you permission to add verbs.

Most libraries and tools support arbitrary verbs including `XMLHttpRequest` and `curl`. Yes, there are a few libraries and frameworks that don't easily support arbitrary verbs, but the ones that have added support for PATCH generally have opened up.

Look, there are two Internets. One for people and one for machines. Our RESTful APIs are intended for consumption by machines, not people. You don't have to wedge everything into GET and POST and abuse query parameters to convey what you really mean.

[1] http://tools.ietf.org/html/rfc7231#section-4.1

View on HN

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

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.

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...

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.

Thanks for the link -- I never knew of http://www.iana.org/assignments/http-methods/http-methods.xh... before. :-o

The most commonly implemented verb I see is PURGE, for clearing a particular url out of a reverse proxy cache.

Woah, I had no idea this was possible. Guess I'm one of the 10,000 today. Thanks!

Me too, but I'm not sure it's a good idea. I would be worried that caches, firewalls, and servers would mishandle requests due to the exotic verbs.

Reply on news.ycombinator.com