Some of the points of contention:
(1) Should api version go in the URL or accept header?
(2) Should representation type go in the url or accept header?
(3) Are custom HTTP verbs okay?
(4) Should GET, POST, PUT and DELETE map one-to-one to CRUD? Most say no, but other seeming authorities say it's fine.
(5) Should you ever return a URL template, and a set of entity identifiers that can be plugged in, or should you only return the fully formed URLs?
(6) What is the difference between a URL and a URI? (And all you who say this one is dead simple and I'm an idiot for not knowing, see if your answers actually agree with each other)
(7) Are two different language translations of a document different resources, or are they different representations of the same resource?
(8) If two different language translations are just different representations of the same resource, how should the client indicate which version it wants?
And of course some people say that a few of these questions aren't even within the scope of REST anyway.
1. Possibly both (the one in the URL being the version of the URL-space and the one in the Header being the more fine grained Representation Version).
2. It depends. For simplicity it often makes sense to put it in the URL. For more generality headers can be better.
4. They don't have to. They usually do though and it makes most sense when they do.
5. Fully formed URLs are simpler, so go with those if you can. But sometimes you'll need more.
6. URLs are a subset of URIs. All URLs are URIs. URLs give the location of the resource whereas URIs just have to identify it (but could also give the location of course.
7. It depends. I lean towards different but I'm no authority.
8. Using the Accept-Language header. But I'm guessing this is not always the best way to do things.