On of the common mistake I often encounter is considering too much about RESTful standard and naming convention: Is PUT better than POST in this situation? Should this API be POST .../upvote or PUT .../upvotes? Should comments be an independent resource or a sub-resource under posts ?
All these hesitations above could not make the design better, only to distract you from focusing on the core value of the API design. An API is how you think your service should communicate with others, what really matters is its readability, clarity, and maintainability, you should not care too much about whether it is RESTful-suited or not, you need to make it easy to read and understand, the parameters can reflect its calling process clearly, the data it returns could be forward/backward compatible in the future ... and so on. RESTful and SOAP and RPC are just good practices to reference, not strict standards to follow, a good designer can take the good parts and make the best API design in current situation accordingly.