The document discusses testing REST APIs using Java. It covers creating test cases to test API functionality, parameters, and expected results. It also discusses best practices for organizing test cases and ensuring complete test coverage. The document then describes how to perform automated testing of APIs using Java tools like POJOs, serialization/deserialization, Rest-Assured, and assertion libraries. It provides details on HTTP methods like GET, POST, PUT, DELETE and important HTTP headers.

1. REST API TEST
By Anil Upadhyay

2. Test Case Creation
• Understanding the functionality of the API program and
clearly define the scope of the program
• Apply testing techniques such as equivalence classes,
boundary value analysis, and error guessing and write test
cases for the API
• Input Parameters for the API need to be planned and
defined appropriately
• Execute the test cases and compare expected and actual
results.

3. Basic Practice of API Testing
• Test cases should be grouped by test category
• On top of each test, you should include the declarations of the APIs being
called.
• Parameters selection should be explicitly mentioned in the test case itself
• Prioritize API function calls so that it will be easy for testers to test
• Each test case should be as self-contained and independent from
dependencies as possible
• Call sequencing should be performed and well planned
• To ensure complete test coverage, create test cases for all possible input
combinations of the API.

4. Automated Testing of APIs
using Java
• Plain Old Java Object (POJO)
• Serialisation & Deserialisation
• Rest-assured
• Any Java Assert Library

5. POJO
• Plain Old Java Object (POJO): Pojo in Java stands for Plain Old Java Object and they are
used for increasing the readability and re-usability of a program. They are normal java
objects, unbounded by special restrictions, other than the ones forced by the Java
Language Specification.
• In simpler terms, Pojo is defined as a pure data structure, containing the getter and setter
fields. It has the ability to override certain methods from Object or an interface such as
Serializable.
• A POJO must not :
• Extend pre-specified classes: Ex- public class Test extends javax.servlet.http.HttpServlet is
not considered to be a POJO class.
• Contain pre-specified annotations: Ex- @javax.persistence.Entity public class Test{..} is not
a pojo class.
• Implement prespecified interfaces: Ex- public class Test implements javax.ejb.EntityBean {
… } is not considered to be a POJO class.

6. Serialisation &
Deserialisation
• Serialisation is a mechanism of converting the state of an object into a byte stream. Deserialisation is the reverse process
where the byte stream is used to recreate the actual Java object in memory. This mechanism is used to persist the object.

7. HTTP METHODS
• HTTP defines a set of request methods to indicate the
desired action to be performed for a given resource.
Although they can also be nouns, these request methods
are sometimes referred as HTTP verbs. Each of them
implements a different semantic, but some common
features are shared by a group of them: e.g. a request
method can be safe, idempotent, or cacheable.
• GET : The GET method requests a representation of the
specified resource. Requests using GET should only
retrieve data.

8. HTTP METHODS
• POST: The POST method is used to submit an entity to
the specified resource, often causing a change in state or
side effects on the server.
• PUT: The PUT method replaces all current
representations of the target resource with the request
payload.
• DELETE: The DELETE method deletes the specified
resource.
• PATCH: The PATCH method is used to apply partial
modifications to a resource.

9. HTTP HEADERS
• HTTP headers let the client and the server pass additional
information with an HTTP request or response. An HTTP
header consists of its case-insensitive name followed by a
colon (:), then by its value. Whitespace before the value is
ignored.
• Headers can be grouped according to their contexts:
• General headers apply to both requests and responses, but
with no relation to the data transmitted in the body.
• Request headers contain more information about the resource
to be fetched, or about the client requesting the resource.

10. HTTP HEADERS
• Response headers hold additional information about the
response, like its location or about the server providing it.
• Entity headers contain information about the body of the
resource, like its content length or MIME type.

11. IMPORTANT
HEADERS
• Authorization
• Contains the credentials to authenticate a user-agent with a
server.
• Connection
• Controls whether the network connection stays open after the
current transaction finishes.
• Keep-Alive
• Controls how long a persistent connection should stay open.

12. IMPORTANT
HEADERS
• Accept
• Informs the server about the types of data that can be sent back.
• Accept-Language
• Informs the server about the human language the server is expected to send back. This is a
hint and is not necessarily under the full control of the user: the server should always pay
attention not to override an explicit user choice (like selecting a language from a dropdown)
• Content-Length
• The size of the resource, in decimal number of bytes.
• Content-Type
• Indicates the media type of the resource.
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers

13. The GET Method
• GET is used to request data from a specified resource.
• GET is one of the most common HTTP methods.
• GET requests can be cached
• GET requests remain in the browser history
• GET requests can be bookmarked
• GET requests should never be used when dealing with sensitive data
• GET requests have length restrictions
• GET requests are only used to request data (not modify)

14. The GET Method
Syntax
GET /index.html

15. The POST Method
• The HTTP POST method sends data to the server. The type of the
body of the request is indicated by the Content-Type header.
• The difference between PUT and POST is that PUT is idempotent:
calling it once or several times successively has the same effect
(that is no side effect), where successive identical POST may have
additional effects, like passing an order several times.POST
requests are never cached
• POST requests do not remain in the browser history
• POST requests cannot be bookmarked
• POST requests have no restrictions on data length

16. The POST Method
POST /test HTTP/1.1
Host: foo.example
Content-Type: application/x-www-form-urlencoded
Content-Length: 27
field1=value1&field2=value2

17. The PUT Method
• The HTTP PUT request method creates a new resource or replaces a representation of the target
resource with the request payload.
• The difference between PUT and POST is that PUT is idempotent: calling it once or several times
successively has the same effect (that is no side effect), where successive identical POST may
have additional effects, like passing an order several times.

18. The DELETE Method
• The HTTP DELETE request method deletes the specified
resource.