API Workshop
By Amol Chitanand
Techno-Functional
Role
API Introduction
• API which stands for Application Programming interface is an interface between
different software so that they can interact with each other very smoothly.
• API is used to access different software services such as retrieve data, add user
inputs, update/ remove existing data and automate processes
• The API is also called a middleman between two systems, it helps in data
monetization & helps in improving collaboration.
• SOAP (Simple Object Access Protocol) & REST (Representational State Transfer)
using the these to build & access web services as packets of API(s).
• APIs are of different types, each has its specific purpose and usage for the
applications. We will explore 4 primary types of APIs: Public APIs, Private
APIs, Composite APIs, and Partner APIs.
Open APIs
➢ It is also called public APIs which are available to any other users.
➢ Open APIs help external users to access data and services. It is an open-source
application programming interface that we access with HTTP protocols.
➢ These types of APIs are available to the public by companies, allowing external users
to access specific functionalities or data.
➢ It is a very popular type of API in modern API development, which involves
consistency, reusability, and easy integration of services and data from different
platforms.
➢ It has a developer-friendly environment but the developers who create these Open
APIs have to be well aware of the documentation to the efficient usability of API.
Internal APIs
➢ It is also known as private API, only an internal system exposes this type of
API.
➢ These are designed for the internal use of the company rather than the external
users.
➢ As Private APIs are used for internal use, data formats can be negotiated,
depending on the use cases. These can also be created for better collaboration of
data and services among the different teams.
➢ It has a very controlled environment within the organization so the utilization of this
API is more effective and promotes collaboration, and reusability, and ultimately
leads to a more productive development process.
Composite APIs
➢ It is a type of API that combines different data and services.
➢ The main reason to use Composites APIs is to improve the performance and speed
up the execution process and improve the performance of the listeners in the web
interfaces. Sometimes, interacting with some websites contains a very complex and
time-consuming process, so to solve this problem, we use Composite API.
➢ It allows developers to access a set of related functionalities through a single API
endpoint which simplifies the complex interactions and provide a great user
experience.
Partner APIs
➢ It is a type of API in which a developer needs specific rights or licenses in
order to access. Partner APIs are not available to the public.
➢ These APIs are provided by third-party companies that allow external developers to
access their services and integrate them into their applications.
➢ It is a very secure and controlled way for external systems to collaborate with the
company and access the capabilities of our system.
➢ One of the best examples of Partner API is Amazon API which allows online
businesses to connect with [Link] by providing various functionalities like
inventory management, shipping options, and analytics of their business.
What is REST API?
As REST is an acronym for Representational State Transfer, statelessness is key. An
API can be REST if it follows the below constraints. The REST architectural style
describes six constraints. These constraints, put on the architecture, were initially
communicated by Roy Fielding in his doctoral dissertation and defines the basis of
RESTful-style.
[Link] Interface
2. Stateless
3. Cacheable
4. Client-Server
5. Layered System
6. Code on Demand
Uniform Interface The uniform interface constraint defines the interface between clients and servers. In
other terms, First constraint of the REST API states that the Client and server has to communicate and
agree to certain rules based on resources(they should communicate with same resource like json, xml,
html , txt) and with proper encoding like UTF-8 extra. Another point they should communicate with the
Self-descriptive Messages e.g Use the same MIME types.
Stateless APIs in REST are stateless and Client and server doesn’t worry about the state of the request
or response. Web services can treat each method request independently.
Cacheable According to the World Wide Web, clients can cache responses. Responses should
therefore, implicitly or explicitly, define themselves as cacheable. Its upto server when they want the
cache to expired etc.
Client-Server Client and Server are two different entity, It means that servers and clients may also be
replaced and developed independently, as long as the interface is not altered.
Layered System. It means that the between client and server there can be any number of layered
systems it does not matter.
Code on Demand Server can store the Code or logic to themselves and transfer it whenever needed
rather client side logic. If any API fulfill all the constraints then we can it REST AP
Difference between REST API vs SOAP API
Feature REST API SOAP API
Architecture Follows REST architectural style Uses SOAP protocol
Uses HTTP/HTTPS as the communication Can use HTTP, SMTP, or TCP/IP as
Communication
protocol transport protocols
Uses lightweight formats like JSON or
Message Format Uses XML for message payloads
XML for payloads
Flexible and scalable, suitable for web More rigid and less flexible, often
Flexibility
applications used in enterprise
Generally easier to understand and More complex due to strict standards
Ease of Use
implement and XML contracts
SOAP API
SOAP (Simple Object Access Protocol) is a messaging
protocol that allows programs that run on disparate
operating systems or services like frontend or backend
to communicate using Hypertext Transfer Protocol
(HTTP) and its Extensible Markup Language (XML).
SOAP uses WSDL is an XML format for describing network
services as a set of endpoints operating on messages
containing either document-oriented or procedure-oriented
information
REST API
➢ A REST API, or Representational State Transfer Application
Programming Interface, is a type of web service architecture that allows
communication between different software systems over the internet.
➢ It follows the principles of REST, which include statelessness, client-
server architecture, uniform interface, cacheability, layered system, and
optionally, code on demand.
➢ REST APIs use standard HTTP methods (GET, POST, PUT, DELETE,
PATCH, OPTIONS) to perform CRUD (Create, Read, Update, Delete)
operations on resources identified by Uniform Resource Identifiers
(URIs).
➢ They enable systems to interact with each other by exchanging data
representations, typically in formats like JSON or XML, using the
Hypertext Transfer Protocol (HTTP)."
Resources and Representations
•Resources: Abstractions of data or services that can be identified by a URI.
•Structure of a URI (a URL):
•Representations: Different representations of resources (e.g., JSON, XML)
used for communication between client and server.
The Main Components of REST
The REST interfaces contain different components, each of which are explored
in subsequent sections:
● Request URI
● Request Headers
● Request Body
● Response Headers
● Response Codes
● Response Body
Request URI
A request URI is typically of the form: [Link] Top
Level Domain (TLD) represents the host name or the IP address. The resource can be a
hierarchical name (e.g. search/b/c) or a simple name (e.g. search). The query string at the
end is a collection of key value pairs, for example:
[Link]
● the TLD is [Link]
● the resource is search
● the Query String is ?q=Bangalore+Club&search=&form=QBLH The variable parts of the
request URI are either in the resource part or in the query string or in both places
Request Headers
These are the request headers that are commonly present in http requests:
● Accept: specify desired media type of response
● Accept-Language: specify desired language of response
● Date: date/time at which the message was originated
● Host: host and port number of a requested resource
● If-Match: conditional request
● Referrer: URI of previously visited resource
● User-Agent: identifier string for web browser or user agent. Based on
this header, the server usually sends a customized response for
different browsers. For example, a mobile app will be sent a smaller
amount of content (only important content) as compared to a browser
from a desktop.
● Cookie: matched cookies for state maintenance
Request Body
➢ A REST request has an optional request body component that is commonly present in methods other than
GET.
This body can contain detailed data, large documents which usually cannot be sent as part of a URL
➢ They are term as tags
Response Headers
These are the commonly found response headers in the http response:
● Allow: list the REST methods supported by the request URI
● Content-Language: language of the response content
● Content-Type: media type of representation, where typical content types
are text/html, application/json, etc.
● Content-Length: length in bytes of the representation
● Date: date/time at which the message was originated
● Expires: date/time after which the response is considered obsolete
● Last-Modified: date/time at which the representation was last changed
● Set-Cookie: sets cookies for the domain. This is useful for maintaining the
state, as http basically is stateless.
Response Body
The response body is the content returned from the server in response to a REST method
call. Typically, this response is in form of JSON.
JSON stands for JavaScript Object Notation.
This is a lightweight data format used for storing and transporting data.
JSON is easy to understand and is self-explanatory.
Response Codes
There are five categories of response codes. The response codes of http are summarized below:
● 1XX: Informational
● 2XX: Success
200 OK, 201 Created, 202 Accepted, 204 No Content
● 3XX: Redirection
300 Multiple Choices, 301 Moved Permanently, 302 Moved Temporarily,
304 Not Modified
● 4XX: Client Error
400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 405 Method not allowed
● 5XX: Server Error
500 Internal Server, Error 502 Not Implemented
Common HTTP status codes
1xx Informational:
1. 100 Continue: The server has 4xx Client Error:
received the initial part of the 1. 400 Bad Request: The server cannot process the request
request and is waiting for the due to a client error.
client to send the remainder. 2. 401 Unauthorized: The request requires user
authentication.
3. 403 Forbidden: The server understood the request but
2xx Success: refuses to authorize it.
1. 200 OK: The request has succeeded. 4. 404 Not Found: The requested resource could not be
2. 201 Created: The request has been fulfilled and a new found.
resource has been created. 5. 405 Method Not Allowed: This status code indicates that
3. 204 No Content: The server successfully processed the resource specified by the request exists, but the
the request but there is no content to return. requested HTTP method is not allowed or wrong.
5xx Server Error:
1. 500 Internal Server Error: The server encountered an
3xx Redirection: unexpected condition that prevented it from fulfilling
1. 301 Moved Permanently: The requested the request.
resource has been permanently moved to a 2. 502 Bad Gateway: The server received an invalid
new location. response from an upstream server while trying to fulfill
2. 302 Found: The requested resource the request.
temporarily resides at a different URI. 3. 503 Service Unavailable: The server is currently
3. 304 Not Modified: The resource has not been unable to handle the request due to temporary
modified since the last request. overload or maintenance.
4. 599 Network Connect Timeout Error: The server
connection has timed out with client.
HTTP Methods
•GET: Retrieve resource representation.
•POST: Create a new resource.
•PUT: Update an existing resource or create a new one if it doesn't exist.
•DELETE: Remove a resource.
•PATCH: Partial update of a resource.
•OPTIONS: Retrieve information about available methods for a resource.
GET: Retrieve resource representation.
GET is the preferred method for accessing a resource on the internet. Hence it
is equivalent to the Read operation in databases. Much like the SELECT clause
in SQL, you request to return a set of data items. The format of a GET request
varies in terms of the underlying URI. The URI format is dependent upon the
application provider.
The important characteristics of the GET request are
outlined below. A GET request:
● is a read-only request
● does not modify any resource
● is idempotent, i.e., when you request the same resource twice, it should
give the same response
● puts all the content in the URI
● typically, does not put anything in the body
● URI can take at best 64 KB of data
● is not encouraged when there is a need to send secured data
POST: Create a new resource.
POST is usually used when there is a need to send content of more than 64KB,
even for a database read operation.
The important characteristics of the POST
request are listed below.
A POST request:
● is used for sending secured data
● uses simple URIs but sends most content in the request body part
● as it typically corresponds to the database operation of creating a record,
it is recommended when there is a need to create a new resource on the
server
● is not idempotent
PUT Method - Perform invocation of a PUT REST request.
As it typically corresponds to the database operation of updating a record, PUT
method is recommended when there is a need to update an existing resource on
the server.
The important characteristics of the PUT request are listed below.
A PUT request:
● is idempotent
● may use content in URI or in BODY
● updates the entire record, so all the field values (updated) should be
provided
PATCH: Partial update of a resource
PATCH is the same as PUT, except that you can do a partial update of the
resource on the server, unlike PUT, where all the fields are updated. As a
result, you can update one or two fields as well.
•DELETE: Remove a resource.
The DELETE method is used to indicate to the server to delete a stated resource.
API Testing in the Test Pyramid
• In a typical test pyramid, API testing, also referred
to as service testing, is below the UI testing, and
above unit testing.
• It can be viewed at the level of system integration
testing.
• Typically, several varieties of UIs can be built using
reusable APIs, which offer reusable data and
methods to be passed on the UI layer.
• In general, APIs are of higher granularity than UIs.
Advantages of API Testing vs. GUI Testing
● the APIs describe stable contracts and do not change too often, leading to
lower maintenance costs of APIs
● the API layer offers a reusable resource used in multiple APIs, the actual
logic inside the APIs is tested before the GUI layer.
● the concise interfaces, which describe the APIs, render the testing of
APIs less time consuming.
● language independent due to XML/JSON as content – a key benefit of
APIs is the language independence due to the use of XML or JSON,
which reduces the number and variety of test cases to be tested.
Common API Test Cases
▪ Verify that the API response status code is 200 OK for GET Method.
▪ Verify that the API response is in the expected format (e.g. JSON, XML).
▪ Verify that the API response contains all the expected fields – Resources or Parameters.
▪ Verify that the API response contains the correct data for each field – Values against each Parameter.
▪ Verify that the API response time is within acceptable limits. (if, Performance is being evaluated)
▪ Verify that the API request parameters are sent to Endpoint successfully for GET, POST, PUT. (200)
▪ Verify that the API request method is correct (e.g. GET, POST, PUT, DELETE).
▪ Verify that the API endpoint URL - URI is correct.
▪ Verify that the API response headers are correct.
▪ Verify that the API returns a success message if the resource is created successfully. (201)
▪ Verify that the API returns an error message if the request is malformed – Syntax Errors (400)
▪ Verify that the API returns an error message if the authentication fails. (401)
▪ Verify that the API returns an error message if the request payload is missing – resource empty. (400)
▪ Verify that the API returns an error message if the requested resource does not exist. (400)
▪ Verify that the API returns an error message if the requested resource is not authorized. (402)
▪ Verify that the API returns an error message if the request payload exceeds the allowed limit. (413)
▪ Verify that the API returns an error message if the request payload contains invalid resource – wrong data
type. (400)
▪ Verify that the API returns an error message if the request method is not allowed for the URI. (405)
▪ Verify that the API returns a success message if the resource is updated successfully. (200 if Body has
content) & (204 if Body has no content)
Application of the Positive Testing of APIs
Positive testing is a type of software testing that is performed by assuming everything will
be as expected.
Positive testing is not limited to payload and body, but it also applies to headers also.
If positive test cases fail, this shows its implementation was not complete.
Typical positive test cases for APIs involve the following tests from a functional
testing perspective:
● testing for headers in response
● testing for headers in request
● testing for right response codes
● testing of valid values in fields/ resources
● testing of values in fields in parameters
● testing of API response bodies compliance to JSON schema/XML schema
● testing of response content parts in JSON or XML body or plain text
Negative Testing of APIs
Negative testing is a type that is performed by feeding wrong data to the APIs &
examining the behavior. If negative tests fail, it indicates improper exception handling.
Due to incomplete negative testing, APIs fail in real world when fed wrong data.
Typical negative test cases are listed below:
● field values of illegal type (not of allowed type) in input
● field values out of bounds (allowed range) in input
● field value is null while it is mandatory
● field is omitted – resource is missing
● duplicate fields
● invalid XML or JSON not conforming to schema
● empty request
● invalid request header (an important header)
● in security, sending wrong token or credentials
● sending wrong METHOD (PUT instead of GET)
● no data in body when it expects data