Read the API carefully as you write it. Does it read clearly? Can new users make sense of it quickly? Twitter’s “statuses/mentions” is a good example – you’ll HTTP GET the mentions of the user account you’re calling from. Readable APIs mean easy-to-adopt APIs.
Your API exists for the use of developers. You’ll probably get it wrong the first time. With a tight feedback loop between developers who use the API and those who build the API you can get it right quickly. In turn these early users will help promote the API and help new users get productive.
The accepted verbs for REST APIs are contained in the HTTP Request: GET and POST. Realistically PUT and DELETE are not always available due to IT standards for security on web servers. Try to design your interface from the point of view of using just GET and POST as your verbs.
Joe Gregorio’s original column from 2004 is just as relevant today as it was then. It covers the four fundamental design questions that authors of a REST API must ask and answer. Find it here: http://www.xml.com/pub/a/2004/12/01/restful-web.html
Ideally an API exposes a resource that can be manipulated. While there may be multiple ways to organize those resources into categories and lists, at the end of the URL you are exposing a resource. This is a core principle of the REST pattern. Look at the problem from the resource’s perspective, not the perspective of the method.