[lloeki]

The author proposes:

    POST /articles/{articleId}/submit
    POST /articles/{articleId}/approve
    POST /articles/{articleId}/decline
    POST /articles/{articleId}/publish

I find this troublesome because the URL path component then includes a verb, an action, so there are two verbs in the same sentence!

This can be adjusted to:

    POST /articles/{articleId}/submitted
    POST /articles/{articleId}/approved
    POST /articles/{articleId}/declined
    POST /articles/{articleId}/published

Now the URLs really represent resources on which HTTP verbs operate, and you can readily guess what GET (if needed/applicable) on each resource would give you.

There is some cognitive dissonance introduced by the inconsistency of abstraction levels between the former "RPC style" (where HTTP verbs are mere actuators† and the intent is in the URL and/or in the payload), and the latter "REST style" (where verbs carry intent acted upon resources).

EDIT: I do not advocate for one over the other, merely that an API should be consistent overall and not mix both.

† They are used as pure HTTP feature control (like caching) and do not carry application-level semantics.