How to approach API testing?



  • This is one of the most common needs today and consequently a common interview question.

    This question is intended to be a canonical answer to the general question of "How do I test an API". Other questions in this vein are more specific. For this question I am going high-level as indicated by the short question title.



  • API Test Checklist

    • Endpoints
    • Actions
    • Status Codes
    • Payload Data
    • Performance
    • Security

    Specifically

    • Verbs / Actions / Methods
    • 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 workflows1 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 ?
    • Is the API restricted to a country or region ?
    • What (if any) versioning approach is used ?
    • Does the API support Multiple Languages ?
    • If already using SOAPui, how is it integrated ?
    • Does it provide client stubs in specific languages ?
    • What status codes are expected for given endpoints ?
    • Does the API use HATEOS2 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 ?
    • What non-API approaches will be needed to prepare data ?
    • Are there existing API definitions e.g. WADL, WSDL, Thrift ?
    • 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 ?

    Practically

    Here are some more specific things to check in a HTTP based API:

    • Can I change the ID in a put call ?
    • Can I PUT an object with an invalid ID ?
    • Can I POST an object with an existing ID ?
    • Can I GET an object I am not authorized to get ?
    • Can I PUT an object that I am not authorized for ?
    • Can I GET an object I am not authenticated to get ?
    • Does deleting require Authentication / Authorization ?
    • Can I POST an object that I am not authenticated for ?
    • Can I access hidden information without authorization ?
    • Can an attacker determined which resources routes exist by 401 vs 404 ?
    • Can I search for information that I am not allowed to see available directly through a route ?
    • Does deleting a parent or (only 1) referenced record delete the associated record as expected ?

    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. Also known as Hypermedia.


Log in to reply
 

Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2