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