1 Understand the full scope of secure API consumption
Testing Strategy for APIs
While testing APIs, a tester should concentrate on using software to make APIcalls in order to receive an output before observing and logging the system’sresponse. Most importantly, tests that the API returns a correct response oroutput under varying conditions. This output is typically one of these three: * A Pass or Fail status * Data or information * A call to another APIHowever, there also could be no output at all or something completelyunpredicted occurs. This makes the tester’s role crucial to the applicationdevelopment process. And because APIs are the central hub of data for manyapplications, data-driven testing for APIs can help increase test coverage andaccuracy.In testing the API directly, specifying pass/fail scenarios is slightly morechallenging. However, in comparing the API data in the response or incomparing the behavior after the API call in another API would help you setupdefinitive validation scenarios.API testing is one of the most challenging parts of the whole chain ofsoftware testing and QA testing because it works to assure that our digitallives run in an increasingly seamless and efficient manner. While developerstend to test only the functionalities they are working on, testers are incharge of testing both individual functionalities and a series or chain offunctionalities, discovering how they work together from end to end.
Types of API Testing
First, identify what type of tests you need to perform on API. Like testers dodifferent type of testing for features of their product, the same goes forAPIs. Common testing of APIs includes: * Unit Testing: To test the functionality of individual operation. For example, Google provides geocoding API to get the longitude and latitude of any location. This usually takes the address as input and returns lat-longs. Now for unit testing of this API, the tester may pass different location and verify the result. * Functional Testing: This type of testing mainly focuses on the functionality of API. This would include test cases to verify HTTP response codes, validation of response, error codes in case API return any error, etc. * Load Testing: This type of test is necessary in cases where API is dealing with huge data and chances of application to be used by no.of users at the same time. This increases the API hits at the same time and it may crash and not able to take that load. * Security Testing: Security testing is particularly critical as API are used to create a link between two different applications. The core purpose of using an API is to abstract or hide the application’s database from other. This may include test cases like authorization checks, session management, etc. * Interoperability Testing: This is to test that API is accessible to the applications where it should be. This applies to SOAP APIs. * WS compliance Testing: API is tested to ensure standards such as WS-Addressing, WS-Discovery, WS-Federation, WS-Policy, WS-Security, and WS-Trust are properly implemented and utilized * Penetration Testing: This is to find the vulnerability of API from external sources.
Web Services/API Protocols
If we talk about web services there are mainly two types of services or,protocols-REST – REST stands for REpresentational State Transfer which is new on theblock as compared to SOAP which means it must overcome all the problems withSOAP. REST is a lightweight protocol which uses URL for all the neededinformation. It uses four HTTP methods to perform task- 1. `Get` – To get the information. For example getting longitude and latitude in case of location mapping API. 2. `Post` – To insert some data in resource. 3. `Put` – To update the resource. 4. `Delete` – To delete from resource.REST is more used now due to its simple and lightweight architecture.SOAP stands for Simple Object Access Protocol. It uses XML for messageexchanging. All the information which is required to perform this task isgiven in its WSDL which is Web Service Description Language. SOAP is heavyweight due to its extensive used standards and XML. The main advantages ofSOAP over Rest is that it has built in error handling and it can be used withother protocols like SMTP.
Tools for API Testing and Automation
There are several tools to test the APIs. When a tester gets to test an API,they must ask for its document, whether it is a REST or SOAP API or its not-web based API there should always be a document where the details should bewritten. To approach API testing 1. Ask for Doc 2. Write functional or service level cases first 3. Write integration tests 4. When API is stable enough and passes most of the above tests, perform security, performance and load testing. * A typical API doc has all the information related to the API like its request format, response, error codes, resource, mandatory parameters, optional parameters, headers, etc. The doc can be maintained in various tools like Swagger which is open source. * After that, try to write service-level cases for the API. For example, if an API takes n parameters to get the response in which m are mandatory parameters and others are optional, then one test case should be to try different combinations of parameters and verify the response. Another test case might verify the headers and try to run API without passing authentication and verify the error code. * Next comes the step of integration testing, where you need to test the API and all its dependent APIs or functions. This also includes testing API response, the data it should return to another API or method and what happens if this API fails. * Once the API is stable and functional testing is almost done, the tester can perform load, security and performance testing.
We often need to automate the test cases which are repeatedly executed, likeregression cases. Similarly, in the case of API testing, there might be somecases in which we need to execute before every release and those cases can beautomated.There are many tools for API automation which are quite popular: 1. SOUP UI 2. Katalon studio 3. Postman 4. Jmeter 5. RestAssured 6. CloudQA TruAPI * SOUP UI: It’s a very popular tool for API testing. You can do functional, load, security and compliance tests on your API using SoapUI. * Katalon Studio: Built on the top of Selenium and Appium, Katalon Studio is a free and powerful automated testing tool for Web testing, API testing, and Mobile testing. * Postman: Postman is free and helps you be more efficient while working with APIs. It has all the capabilities to develop and test APIs. * JMeter: Though JMeter is mostly used for performance and load testing, it can also be used for API functional testing to a good extent. * RestAssured: Rest-Assured is a Java-based library that is used to test RESTful Web Services. The library can be included in the existing framework and call its methods directly for fetching response in JSON format and then perform required actions.I am taking an example to explain the steps followed for basic API functionaltesting, here I am using TruAPI tool provided by CloudQA.To run API request you need to first select the Method Type and paste URL ofthe API. Press Send button to send the request to API or press Add API Testbutton to save the request: Try this sample Method Type and API URL * Method Type: `GET` * API URL: https://um5fdww2pj.execute-api.us-east-1.amazonaws.com/dev/todos
Information for the API Request
* Most of the API require additional inputs to perform the request such as parameters, Headers, Body (JSON), and so on. * To add parameters of the request you can select the respective Parameters tab and press the Add Parameter buttons to add the required information.
Public APIs and API integration
APIs are a longstanding concept in computer programming, and they have beenpart of developers’ toolsets for years. Traditionally, APIs were used toconnect code components running on the same machine. With the rise ofubiquitous networking, more and more public APIs, sometimes called open APIs,have become available. Public APIs are outward facing and accessible over theInternet, allowing you to write code that interacts with other vendors’ codeonline; this process is known as API integration.These kinds of code mashups allow users to mix and match functionality fromdifferent vendors on their own systems. For instance, if you use the marketingautomation software Marketo, you can sync your data there with Salesforce CRMfunctionality.“Open” or “public” should not be interpreted as meaning “free of charge” inthis context. You still need to be a Marketo and Salesforce customer for thisto work. But the availability of these APIs makes integration a much simplerprocess than it otherwise would be. (InfoWorld has a great list of public APIsyou should know about.)
Web services and APIs
You might recall the term web services from the early ’00s and think that theidea of an open API sounds pretty similar. In fact, a web service is aspecific kind of open API, one that meets a fairly rigid set ofspecifications, including that they be specified in Web Services DescriptionLanguage (WSDL), an XML variant.Web services were meant to be used as part of a service-oriented architecture(SOA). As the Nordic APIs blog explains, that gave web services something of abad name, as SOAs never quite lived up to their potential. Advances in thetechniques used for service-to-service communications—notably lighter, moreflexible REST—have also left web services somewhat behind in the world ofpublic APIs.
Web services were originally designed to communicate using SOAP (Simple ObjectAccess Protocol), a messaging protocol that sends XML documents over HTTP.Today, however, most web-based APIs use REST—Representational StateTransfer—as an architectural style.REST was formally introduced by Roy Fielding in his doctoral dissertation in2000. It’s a set of architectural components, design principles, andinteractions used for building distributed systems that involve media of anykind (text, video, etc.). At its core, REST is a style of building systemsthat allows for flexible communication and display of information across theweb while providing structure necessary to easily build general purposecomponents.In a REST API, a resource could be pretty much anything, but examples includea user, a list of tweets, and the current results of a search for tweets. Eachof these resources is addressable at a resource identifier, which in the caseof web-based REST APIs is usually a URL, such ashttps://api.twitter.com/1.1/users/show?screen_name=twitterdev. When anapplication requests a resource using the identifier, the API delivers thecurrent representation of that resource to the application in a format thatthe application can consume, such as a JPEG image, HTML page, or JSON.One of the big differentiators of REST is that it involves sending data to therequesting application. While this provides great flexibility, allowing theapplication to do whatever it wants with the data, it comes at the cost ofefficiency. Sending data over the web for processing is quite slow compared todoing the processing where the data resides and then sending the results.Of course, the problem with the “efficient” approach is that systems hostingthe data would need to know what applications want to do with it ahead oftime. Thus, in order to build an API that has general purpose usability andflexibility, REST is the way to go.
There are plenty of public APIs out there for you to interact with, many fromindustry behemoths. The ability to access some platform company’s codeprogrammatically via an API is what makes them a platform, in essence. Someprominent API examples include: * Google APIs, which allow you to connect your code to the whole range of Google services, from Maps to Translate. APIs are so important to Google that they acquired Apigee, a leading API management platform. * Facebook APIs, which allow you to programmatically access Facebook’s social graph and marketing tools. (The company has been restricting just what user data you can access via these APIs in the fallout from Cambridge Analytica and other scandals.)To really get a sense of how APIs work, let’s do a deep dive into two: theJava API, which Java developers use to interact with the Java platform, andthe Twitter API, a public API that you would use to interact with the socialnetworking service.
1. Understand the full scope of secure API consumption
Before you build an application or service that consumes third-party data viaAPIs, you must fully understand how they work and the correct way to integratethem. Read API documentation thoroughly — pay particular attention to theprocess and security aspects of the API’s function and routines, such asrequired authentication, call processes, data formats and any potential errormessages to expect. One good approach to this is to build a threat model foryour APIs. This will help you understand the attack surface, identifypotential security issues and incorporate appropriate security mitigationsfrom the beginning.
3. Choose your web services API: SOAP vs. REST
The two dominant options to access web services via APIs are SOAP (SimpleObject Access Protocol), a communications protocol, and REST (RepresentationalState Transfer), a set of architectural principles for data transmission. Theyuse different formats and semantics and require different strategies to ensurerobust security. SOAP security is applied at the message level using digitalsignatures and encrypted parts within the XML message itself. REST reliesheavily on access control rules associated with the API’s universal resourceidentifier, such as HTTP tags and the URL path.Use SOAP if your primary concerns are standardization and security. While bothformats support SSL, SOAP also supports WS-Security. It also has built-inerror handling, and supports identity verification through intermediariesrather than just point-to-point verification as provided by SSL. However, SOAPexposes components of application logic as services rather than data; this canmake SOAP complex to implement, and may require you to refactor anapplication.REST, meanwhile, is compatible with various data output types such as JSON,CSV and HTTP, while SOAP can only handle XML and HTTP. Also, REST merelyaccesses data, so it is a simpler way to access web services. For thesereasons, organizations often prefer REST for web development projects.