HATEOAS? There's an acronym only an academic could come up with...
I'm a bit troubled by whether I actually want to do a REST interface or an "RPC" interface. Informally, they're not necessarily different things -- you can do an RPC interface that's (a) stateless, (b) uses URIs named after resources, (c) uses different HTTP verbs to match the type of action being taken (read with GET, delete with DELETE, create with POST, modify with PUT/PATCH), and (d) can be cached/proxied. And lots of people do.
The other is the aforementioned HATEOAS - "hypertext as the engine of application state". (Seriously. Worst acronym ever.) It's great for generic clients like web browsers that have a human controlling every step -- you put some text in the web page describing something, then a link to it. That's not necessarily a bad thing for an API either -- the implication is that a human should be able to go to the base API url and discover everything about it, just by clicking around. That in turn, is basically a self-documenting API, which, again not a bad thing.
But "the engine of application state" goes further, implying that the client shouldn't make assumptions about the API, but should rather discover it itself through hyperlinks (or downloaded code?). Now again, downloaded code has some appeal here, but if what you're trying to build isn't a website or a webapp, but a command line tool that accesses a server API, I don't think it makes sense to try to make it adapt to http://foo/
changing one of its resources from being names users/ to people/, or to suddenly describing things in XML instead of JSON the same way that you could replace an image with a movie inside a webpage.