Nowadays, web services play a major role in the development of enterprise applications. Many such applications are now developed using a service-oriented architecture (SOA), where microservices is one of its most popular kind. A RESTful web service will provide data via an API over the network using HTTP, possibly interacting with databases and other web services. Testing a RESTful API poses challenges, as inputs outputs are sequences of HTTP requests responses to a remote server. Many approaches in the literature do black-box testing, as the tested API is a remote service whose code is not available. In this paper, we consider testing from the point of view of the developers, which do have full access to the code that they are writing. Therefore, we propose a fully automated white-box testing approach, where test cases are automatically generated using an evolutionary algorithm. Tests are rewarded based on code coverage and fault finding metrics. We implemented our technique in a tool called EVOMASTER, which is open-source. Experiments on two open-source, yet non-trivial RESTful services and an industrial one, do show that our novel technique did automatically find 38 real bugs in those applications. However, obtained code coverage is lower than the one achieved by the manually written test suites already existing in those services. Research directions on how to further improve such approach are therefore discussed.
 Developing APIs as Web Services over HTTP implies adding an extra layer to software, compared to the ones that we would need to develop an API distributed as, for example, a library. This additional layer must be included in testing too, but this implies that the software under test has an additional complexity due both to the need to use an intermediate protocol in tests and to the need to test compliance with the constraints imposed by that protocol: in this case the constraints defined by the REST architectural style. On the other hand, these requirements are common to all the Web Services, and because of that, we should be able to abstract this aspect of the testing model so that we can reuse it in testing any Web Service. In this paper, as a first step towards automating the testing of Web Services over HTTP, we describe a practical mechanism and model for testing RESTful Web Services without side effects and give an example of how we successfully adapted that mechanism to test two different existing Web Services: Storage Room by Thriventures and Google Tasks by Google. For this task we have used Erlang together with state machine models in the property-based testing tool Quviq QuickCheck, implemented using the statem module. In the context of RESTful web-services, connectedness refers to the property wherein every resource in the web-service is reachable from the base resource by successive HTTP GET requests. Presence (or absence) of connectedness has practical implications and hence is an important property of RESTful web-services. In this article, we present an algorithm for testing the connectedness of RESTful webservices. Using a formal specification of the web-service, our algorithm tests the connectedness of a web-service automatically. We also discuss a formal notation we have developed to specify RESTful web-services. Using our notation, we wrote the formal specification for a prototype RESTful web-service which has been developed for internal use in our organisation. Using this specification we employed our method to conduct automated testing of the above webservice. Many functional defects apart from those related to connectedness were detected early during development. This demonstrated that both our specification notation and our testing method are promising innovations in the direction of specification and testing of RESTful web-services. In contrast to the increasing popularity of REpresentational State Transfer (REST), systematic testing of RESTful Application Programming Interfaces (API) has not attracted much attention so far. This paper describes different aspects of automated testing of RESTful APIs. Later, we focus on functional and security tests, for which we apply a technique called model-based software development. Based on an abstract model of the RESTful API that comprises resources, states and transitions a software generator not only creates the source code of the RESTful API but also creates a large number of test cases that can be immediately used to test the implementation. This paper describes the process of developing a software generator for test cases using state-of-the-art tools and provides an example to show the feasibility of our approach. Abstract—Representational state transfer (REST) is an architecturalstyle that has received significant attention fromsoftware engineers for implementing web-services due toits simplicity and scalability. By definition, web-services aredistributed, headless (lacking UI) and loosely coupled. Thispresents the implementers and testers of web-services withchallenges, which are different from those in testing of traditionalsoftware. REST has unique characteristics like uniforminterfaces, stateless communication, caching, etc. This also necessitatestaking a fresh look at web-service testing specificallyin the context of RESTful web-services. A large informaticinfrastructure being developed within our organisation islargely based on service-oriented concepts wherein many of theservices are RESTful. As a part of a research project namedTest-the-REST (TTR), we have developed an approach fortesting RESTful web-services of the above infrastructure. Theproject yielded in a number of novel technical innovations, e.g.a scalable plugin based architecture, an extensible XML basedtest specification format, a method for reusing and composingtest cases for use-case testing etc. A prototype of TTR was usedin testing a RESTful service of the above infrastructure early inthe construction phase. Many bugs were uncovered resulting insignificant value add. In this paper, we present our experienceand insights in developing and using Test-the-REST.