My personal take:
At a high level
Test the API Endpoints, Status Codes and Data with Smoke, Happy and Sad Tests
At a detailed level one needs to ask the following questions.
The answers will guide what and how to test.
- What documentation exists ?
- What functionality it provide ?
- Does it support concurrency ?
- What are the API endpoints ?
- Is the API internal or external ?
- Which endpoints are idempotent ?
- Are endpoints stateless or stateful ?
- Do any workflows*1 vary by client ?
- Are there performance requirements ?
- Do API endpoints make up a workflow ?
- What validations are expected for data ?
- What system or library is behind the API ?
- Do we need to mock dependent services ?
- Does it constrain traffic aka Rate Limiting ?
- What (if any) versioning approach is used ?
- Does the API support Multiple Languages ?
- If already using SOAPui, how is it integrated ?
- Is the API be restricted to a country or region ?
- Does it provide client stubs in specific languages ?
- What status codes are expected for given endpoints ?
- What domain format and structure exists for the data ?
- Does the API use HATEOS*2 for self documentation ?
- What kind of data validation/ testing can be performed ?
- What API is supported by the test framework I’m using ?
- What actions are performed, e.g. GET, PUT, POST etc ?
- Do we need to prepare dependent test data or services ?
- What non-API approaches will be needed to verify data ?
- Are there existing API definitions e.g. WADL, WSDL, Thrift ?
- What non-API approaches will be needed to prepare data ?
- What (if any) Authorization (‘what’) mechanism will be used ?
- What (if any) Authentication (‘who’) mechanism will be used ?
- Who will use it, external programmers or another internal module ?
- What format(s): SOAP, REST, GraphQL, Thrift, ProtoBuffer, Other ?
*1 Workflows often require multiple API calls and may have dependencies between them
*2 HATEOS – Hypertext As The Engine Of Application State, which allows self-discovery of an API