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.

The latest addition to my bookshelf is "Building Microservices" by Sam Newman (O'Reilly). It answers a lot of questions related to this topic. Highly recommended. Nginx provides a preview edition.

In addition to Jos Faber's answers, I'll add...

Consistent responses and errors. Many APIs deliver weird, or HTML responses in error conditions... I suggest when returning json, to always return an object wrapper, error as a property, which should have at least message and code properties.

Another is dates... Use UTC iso8601 dates yyyy-mm-ddTHH:nn:ssZ, out drop the Z for local and tether it with a location, for events... Let the client localize dates.

Last, don't be dogmatic about rest vs RPC, most services should have end points that serve some of each. You'll get some weird interactions if you ban one or the other.

Choosing names and arguments that don't make it clear the tradeoffs. Example

void* AllocateSharedMemory(int sizeInBytes)

When it turns out that AllocateSystemMemory can only allocate in chunks of 16k or more. Think about how a user might use it. What if they start allocating small strings with this function? It might arguably be better to change it to

void* AllocateSharedMemoryBlocks(int blockCount)

By changing the name to MemoryBlocks it makes it clear without docs (at the call point) that it's not in bytes and that you probably need to find out the size of the blocks. Also it makes it clear it's not appropriate for allocating lots of small things.