possible for these tests to be disputed, because there is no individual source of truth for what  the implementation should be doing to meet business needs. In this section, we explore how different test stages in the API Test Pyramid apply to an IBM  API Connect solution. 8.6.3 Test types Unit tests The primary question when discussing Unit Testing is what makes up the smallest, testable,  self-contained component, as derived from the requirements. A unit test for an API should  not  call a back-end service. It should  not  rely on making requests from outside the API Connect  domain and should be executable in any simple IBM API Connect environment. The smallest testable unit for API Connect APIs consist of the four components that make an  API: An API has a primary data representation that is called a resource, which is the conceptual  mapping to a set of entities. The  address  of the resource is displayed as a  Uniform Resource  Identifier (URI)  which is crucial to making an API call.  Addresses  will have tests such as;  An  operation  is the method of a REST API that determines what action to perform on the  resource. The four main HTTP verbs that define the operation are; GET (read), PUT (update),  POST (create), and DELETE (delete).  Operation Unit Tests make requests to valid addresses to ensure that the API exposes only  the verbs that are outlined in the requirement. This test is simply about operation exposure. Simple security tests might also be applicable here like the absence of tokens, client IDs, or  certificates for secure endpoints. But they are unlikely to include more advanced tests such  as OAuth, which would be more applicable in integration tests as multiple calls are needed. Request data  normally refers to a list of headers and the body of data that is passed with an  operation to an address. Tests at this level focus on whether the correct data is provided, the  correct headers are used, and that incorrect headers or malformed data are handled  correctly. Response data  normally refers to how the resource call will respond to the request. The data  usually includes a status code, headers, and a body. Tests at this level aim to ensure that  valid and expected output is received when certain requests are passed into the system.  Additional tests will be used for the handling of both successful and failure scenarios.  The simplest unit test topology is shown in Figure 8-20 on page 565. 564  Accelerating Modernization with Agile Integration GLYPH<SM590000> Its address GLYPH<SM590000> Its operation GLYPH<SM590000> Request data GLYPH<SM590000> Response data GLYPH<SM590000> Does an exposed address return a correct result?  GLYPH<SM590000> Are unspecified addresses correctly handled?  GLYPH<SM590000> Are misspelled addresses correctly handled?