To elaborate a bit – after a lot of confusion and wondering, I came to the conclusion that REST is just a very poorly defined buzzword. Another conclusion was that it's ok – a good practice in fact – to combine REST and RPC in one API. (Specifically – use REST if you can, otherwise RPC.)
I personally define REST in two different ways, let's call them REST1 and REST2, short versions:
REST1
The API is a set of collections, for example we can have /articles and /comments. We can access individual items by /[collection]/[id]. The API can allow GET, POST, PUT, DELETE operations on both collections and items. Collections are filterable, you can do /articles?author=123 for example. Basically, this like a simple interface over a set of database tables.
REST2
The server has a certain state. The API is a set of views on that state. A view can be defined as a function without side-effects that takes the server state as an argument and returns something, usually encoded in JSON. Every view has a certain URL and can have GET, POST, PUT and DELETE operations allowed. The POST method is allowed only for a special type of view – a collection.
The second definition is more flexible. For example, /fulltextsearch?q=test or /multiply/3/5 would be completely REST2ful. But for some tasks, you would still need RPC, e.g. if you need to change the state in a non-trivial way.
No, REST is not poorly defined, and there is no such thing as a "personal definition". It's not the word's fault that is has come to be abused as a buzzword. It's the fault of the people who abuse it.
Both your examples already fulfill many constraints of a RESTful design, but this makes it level 2 in the maturity model. So far, it's "only" an HTTP API, you need more to reach level 3, mandatory for REST. My points of critique:
1. That /[collection]/[id] thing or /articles?author=123 filter are only RESTful when the server advises the client how to construct the URI with a hypermedia control (e.g. HTML form or URI template, to name popular examples). Because you describe the URI, here, out of bound, it is a violation of REST.
2. I see a distinct lack of link relations between the resources you've named. Indeed, that should be the most prominent part of the description of a RESTful interface! What is the relation between articles and comments collections, or articles and comments items? Employ hyperlinks! Give the links types by coining link relations! (In actuality, don't be tempted to invent that particular wheel, because this model and its semantics are already well-defined by the Atom and AtomPub internet standards.)
3. "REST2" is not more flexible than "REST1", it's the same. Why? Because the HTTP spec already defines whether a method is without side-effects, check chapter §9. You also describe, here, out of bound, which method is applicable to which resource; that's also a violation, instead the server sends the headers Allow/Accept-Post/Accept-Patch, and the client ought to use the OPTIONS method to introspect a resource if it wants to know before trying blindly.
In your RESTful interface description, you should not repeat what is already covered by existing internet standards, concentrate on the things that are new in your problem domain.
Lastly, every RPC problem (a procedure is a verb, e.g. addFunds) can be modelled in a resource-oriented fashion (e.g. PUT /funds), where the nouns are the addressable resources, and the verbs are the HTTP methods. Okay, that was an stupid easy example, but it also holds true for more complex, see http://duncan-cragg.org/blog/post/getting-data-rest-dialogue... ff. If you are to become a talented API designer, you must recognise what the nouns of your problem domain are, and build the system's interaction around them.
I personally define REST in two different ways, let's call them REST1 and REST2, short versions:
REST1
The API is a set of collections, for example we can have /articles and /comments. We can access individual items by /[collection]/[id]. The API can allow GET, POST, PUT, DELETE operations on both collections and items. Collections are filterable, you can do /articles?author=123 for example. Basically, this like a simple interface over a set of database tables.
REST2
The server has a certain state. The API is a set of views on that state. A view can be defined as a function without side-effects that takes the server state as an argument and returns something, usually encoded in JSON. Every view has a certain URL and can have GET, POST, PUT and DELETE operations allowed. The POST method is allowed only for a special type of view – a collection.
The second definition is more flexible. For example, /fulltextsearch?q=test or /multiply/3/5 would be completely REST2ful. But for some tasks, you would still need RPC, e.g. if you need to change the state in a non-trivial way.
I hope it's clear, if not, tell me.