Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 2 down vote favorite
1

We have a URL in the following format

/instance/{instanceType}/{instanceId}

You can call it with the standard HTTP methods: POST, GET, DELETE, PUT. However, there are a few more actions that we take on it such as "Save as draft" or "Curate"

We thought we could just use custom HTTP methods like: DRAFT, VALIDATE, CURATE

I think this is acceptable since the standards say

"The set of common methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot be assumed to share the same semantics for separately extended clients and servers."

And tools like WebDav create some of their own extensions.

Are there problems someone has run into with custom methods? I'm thinking of proxy servers and firewalls but any other areas of concern are welcome. Should I stay on the safe side and just have a URL parameter like action=validate|curate|draft?

share|improve this question
8  
or BADGER (you have to call it four times in succession, and then MUSHROOM twice). My vote? action=curate|draft with a POST. – Robert Harvey Apr 4 at 0:13
3  
As I quote from RFC 1925 again - "In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away." -- if it works, there is no reason to add to http. – MichaelT Apr 4 at 2:29
1  
to be honest, this makes me cry and lough at the same time. – shabunc Apr 4 at 8:29
2  
Nothing wrong, as long as you realize that you're now using a custom protocol and not HTTP. – user16764 Apr 4 at 23:26
1  
@user16764 "The set of common methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot be assumed to share the same semantics for separately extended clients and servers." w3.org/Protocols/rfc2616/rfc2616-sec9.html Therefore it is allowed, and it is still HTTP – Juan Mendes Apr 5 at 1:54
add comment (requires an account with 50 reputation)

1 Answer

up vote 15 down vote accepted

One of the fundamental constraints of HTTP and the central design feature of REST is a uniform interface provided by (among other things) a small, fixed set of methods that apply universally to all resources. The uniform interface constraint has a number of upsides and downsides. I'm quoting from Fielding liberally here.

A uniform interface:

  • is simpler.
  • decouples implementations from the services that they provide.
  • allows a layered architecture, including things like HTTP load balancers (nginx) and caches (varnish).

On the other hand, a uniform interface:

  • degrades efficiency, because information is transferred in a standardized form rather than one which is specific to an application's needs.

The tradeoffs are "designed for the common case of the Web" and have allowed a large ecosystem to be built which provides solutions to many of the common problems in web architectures. Adhering to a uniform interface will allow your system to benefit from this ecosystem while breaking it will make it that difficult. You might want to use a load balancer like nginx but now you can only use a load balancer that understands DRAFT and CURATE. You might want to use an HTTP cache layer like Varnish but now you can only use an HTTP cache layer that understands DRAFT and CURATE. You might want to ask someone for help troubleshooting a server failure but no one else knows the semantics for a CURATE request. It may be difficult to change your preferred client or server libraries to understand and correctly implement the new methods. And so on.

The correct* way to represent this is as a state transformation on the resource (or related resources). You don't DRAFT a post, you transform its draft state to true or you create a draft resource that contains the changes and links to previous draft versions. You don't CURATE a post, you transform its curated state to true or create a curation resource that links the post with the user that curated it.

* Correct in that it most closely follows the REST architectural principles.

share|improve this answer
Thanks for the comments on load balancing, I'll definitely look at that. Do you know of a resource that states whether custom methods are acceptable or not? – Juan Mendes Apr 4 at 1:22
2  
I don't see any advantage to custom methods unless they are a part of a widely supported extension like WEBDAV (and even then, not so much) so I have never looked into it. I would just recommend that you treat these changes as state transformations. The web works just fine with the methods we already have. There's really no good reason to add more unless they make sense as a part of the uniform interface (like PATCH). – Rein Henrichs Apr 4 at 1:24
add comment (requires an account with 50 reputation)

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.