Test that it works, i.e. does the implementation match the specification:

1. Is it reading, writing, updating correctly?
2. Are the responses matching the specification?
3. Have you tried destroying your implementation with horrible but valid parameter combinations?

Test that it’s secure:

1. Is it returning extra fields that it shouldn’t? Could be exposing private stuff or stuff not needed by the client.
2. Can it be overloaded? Standard DOS, Slow Loris (if Apache), computationally complex request parameters etc
3. The other obvious stuff like making sure access is restricted to only those with valid creds or tokens.

Is it readable. You probably want to skip this design point if the API is not for third parties. User (dev) research would be nice here but overkill for most of the stuff we do.

Is it extendable/modifiable. Again, if this API is not for third party consumption then it’s less of a consideration. But still, making it easy to extend and modify allows you to add new features quicker.

1. You could try thinking up future features that you may need to add then experiment extending the interface. If it’s a big pain to fit the new feature the perhaps the design might need some tweaking.