API in Brief

API is an acronym and it stands for Application Programming Interface. This is a set of routines,
protocols, and tools for building Software Applications. APIs specify how one software program
should interact with other software programs.

Routine: a program that performs a particular task. Routine is also known as procedure, function
or subroutine.

Protocols: A format for transmitting data between two systems.

In other words, API stands for Application Programming Interface. Subsequently, it acts as an
interface between two software applications and allows the two software applications to
communicate with each other. Moreover, it is a collection of software functions which can be
executed by another software program.

An Application Programming Interface, API, specifies how some software components should
interact with each other. While many people associate APIs with software libraries, the definition
is broad enough to include Web Services and all types of messaging that SoapUI supports:
SOAP, REST, JMS, JDBC, AMF and HTTP.

API working –
 What is API?
An application programming interface (API) is a specification intended to be used as an interface
by software applications to communicate with each other. An API, enables companies to open up
their applications data and functionality to external third-party developers, business partners, and
internal departments within their own companies. This allows services and products to
communicate with each other and leverage each other’s data and functionality through a
documented interface.
Developers don’t need to know how an API is implemented, they simply use the interface to
communicate with other products and services. API integration power processes throughout
many high-performing businesses that keep data in sync, enhance productivity, and drive
revenue. API use has surged over the past decade, to the degree that many of the most popular
web applications today would not be possible without APIs.
What are the types of APIs:
There are four different types of APIs.
1. Open API / Public API is an open-source application programming interface you can access
with the HTTP protocol. They may require registration, use of an API Key or OAuth, or maybe
completely open. They focus on external users, to access data or services
2. Partner API are application programming interfaces exposed to or by strategic business
partners. Typically, developers can access these APIs in self-service mode through a public API
developer portal. Still, they will need to complete an onboarding process and get login
credentials to access partner APIs.
3. Internal API / Private API are application programming interfaces that remain hidden from
external users. These private APIs aren’t available for users outside of the company and are
instead intended to improve productivity and communication across different internal
development teams.
4. Composite API combines multiple data or service APIs. These services allow developers to
access several endpoints in a single call. Composite APIs are useful in microservices architecture
where performing a single task may require information from several sources.
What are the types of API protocols?
 To leverage these different types of APIs, certain protocols need to be followed. A protocol
provides defined rules for API calls. It specifies the accepted data types and commands. Below
are the different types of protocols for APIs
1. REST (Representational State Transfer) – REST (short for ‘Representational State Transfer’) is a
web services API. REST APIs are a key part in modern web applications, including Netflix,
Facebook, and many others. 70% of public APIs are REST APIs.
2. XML – RPC (Extensible Markup Language – Remote Procedure Call) – These are the simplest
API types. You can develop them by formatting your data in XML and, in turn, making simple
requests to the server via HTTP. However, though easy to develop, XML-RPC APIs are tightly
coupled. To make changes, a new developer would have to go through the XML-RPC’s
documentation to understand how a change in one area could affect another.
3. JSON – RPC (JavaScript Object Notation – Remote Procedure Call) – A JSON-RPC is basically
an RPC API coded in JSON. Like XML-RPC, JSON-RPC APIs are easy to develop and
implement, but they too are tightly coupled, which makes it just as difficult to maintain or update
as XML-RPCs.
4. SOAP (Simple Object Access Protocol) – A SOAP API is similar to REST in that it’s a type of
Web API. SOAP entered the web development scene in the late 1990s, around the time service-
oriented architecture (SOA) took-off. SOAP was the first to standardize the way applications
should use network connections to manage service

What is API?
An application programming interface (API) is a specification intended to be used as an interface
by software applications to communicate with each other. An API, enables companies to open up
their applications data and functionality to external third-party developers, business partners, and
internal departments within their own companies. This allows services and products to
communicate with each other and leverage each other’s data and functionality through a
documented interface.
 Developers don’t need to know how an API is implemented, they simply use the interface to
communicate with other products and services. API integration power processes throughout
many high-performing businesses that keep data in sync, enhance productivity, and drive
revenue. API use has surged over the past decade, to the degree that many of the most popular
web applications today would not be possible without APIs.
What are the types of APIs:
There are four different types of APIs.
1. Open API / Public API is an open-source application programming interface you can access
with the HTTP protocol. They may require registration, use of an API Key or OAuth, or maybe
completely open. They focus on external users, to access data or services
2. Partner API are application programming interfaces exposed to or by strategic business
partners. Typically, developers can access these APIs in self-service mode through a public API
developer portal. Still, they will need to complete an onboarding process and get login
credentials to access partner APIs.
3. Internal API / Private API are application programming interfaces that remain hidden from
external users. These private APIs aren’t available for users outside of the company and are
instead intended to improve productivity and communication across different internal
development teams.
4. Composite API combines multiple data or service APIs. These services allow developers to
access several endpoints in a single call. Composite APIs are useful in microservices architecture
where performing a single task may require information from several sources.
What are the types of API protocols?
To leverage these different types of APIs, certain protocols need to be followed. A protocol
provides defined rules for API calls. It specifies the accepted data types and commands. Below
are the different types of protocols for APIs
1. REST (Representational State Transfer) – REST (short for ‘Representational State Transfer’) is a
web services API. REST APIs are a key part in modern web applications, including Netflix,
Facebook, and many others. 70% of public APIs are REST APIs.
2. XML – RPC (Extensible Markup Language – Remote Procedure Call) – These are the simplest
API types. You can develop them by formatting your data in XML and, in turn, making simple
requests to the server via HTTP. However, though easy to develop, XML-RPC APIs are tightly
 coupled. To make changes, a new developer would have to go through the XML-RPC’s
documentation to understand how a change in one area could affect another.
3. JSON – RPC (JavaScript Object Notation – Remote Procedure Call) – A JSON-RPC is basically
an RPC API coded in JSON. Like XML-RPC, JSON-RPC APIs are easy to develop and
implement, but they too are tightly coupled, which makes it just as difficult to maintain or update
as XML-RPCs.
4. SOAP (Simple Object Access Protocol) – A SOAP API is similar to REST in that it’s a type of
Web API. SOAP entered the web development scene in the late 1990s, around the time service-
oriented architecture (SOA) took-off. SOAP was the first to standardize the way applications
should use network connections to manage services.

What Is a REST API?

REST is basically an architectural style of the web services that work as a channel of
communication between different computers or systems on the internet. The term REST API is
something else.

Those application programming interfaces that are backed by the architectural style of REST
architectural system are called REST APIs. REST API compliant web services, database
systems, and computer systems permit requesting systems to get robust access and redefine
representations of web based resources by deploying a predefined set of stateless protocols and
standard operations.

By these protocols and operations and redeploying the manageable and updatable components
without causing the effect on the system, REST API systems deliver fast performance, reliability,
and more progression.

What Is a SOAP API?

SOAP is a standard communication protocol system that permits processes using different
operating systems like Linux and Windows to communicate via HTTP and its XML. SOAP
based APIs are designed to create, recover, update and delete records like accounts, passwords,
leads, and custom objects.

These offers over twenty different kinds of calls that make it easy for the API developers to
maintain their accounts, perform accurate searches and much more. These can then be used with
all those languages that support web services.

SOAP APIs take the advantages of making web based protocols such as HTTP and its XML that
are already operating the all operating systems that are why its developers can easily manipulate
web services and get responses without caring about language and platforms at all.

Differences:

 REST API has no has no official standard at all because it is an architectural style. SOAP
API, on the other hand, has an official standard because it is a protocol.
 REST APIs uses multiple standards like HTTP, JSON, URL, and XML while SOAP
APIs is largely based on HTTP and XML.
 As REST API deploys multiple standards, so it takes fewer resources and bandwidth as
compared to SOAP that uses XML for the creation of Payload and results in the large
sized file.
 The ways both APIs exposes the business logics are also different. REST API takes
advantage of URL exposure like @path("/WeatherService") while SOAP API use of
services interfaces like @WebService.
 SOAP API defines too many standards, and its implementer implements the things in a
standard way only. In the case of miscommunication from service, the result will be the
error. REST API, on the other hand, don't make emphasis on too many standards and
results in corrupt API in the end.
 REST API uses Web Application Description Language, and SOAP API used Web
Services Description language for describing the functionalities being offered by web
services.
 REST APIs are more convenient with JavaScript and can be implemented easily as well.
SOAP APIs are also convenient with JavaScript but don't support for greater
implementation.
What is SOAP?

SOAP or Simple Objects Access Protocol is a web communication protocol designed for
Microsoft back in 1998. Today, it’s mostly used to expose web services and transmit data over
HTTP/HTTPS. But it’s not limited to them. SOAP, unlike the REST pattern, supports the XML
data format only and strongly follows preset standards such as messaging structure, a set of
encoding rules, and a convention for providing procedure requests and responses.

The built-in functionality to create web-based services allows SOAP to handle communications
and make responses language- and platform-independent.

While most web data exchange happens over REST exchange, SOAP isn’t disappearing anytime
soon, because it’s highly standardized, allows for automation in certain cases, and it’s more
secure. Let’s have a look at the main SOAP features.

SOAP works with XML only

Web-transmitted data is usually structured in some way. The two most popular data formats are
XML and JSON.

XML (or Extensible Markup Language) is a text format that establishes a set of rules to structure
messages as both human- and machine-readable records. But XML is verbose as it aims at
creating a web document with all its formality. JSON, on the other hand, has a loose structure
that focuses on the data itself. Have a look at the image below to get the idea.
As we’ve mentioned, when sending requests and response messages within web applications,
SOAP requires XML exchange between systems. And when the request is received, SOAP APIs
send messages back XML-coded only.

Besides the data format, SOAP has another level of standardization – its message structure.

SOAP message structure

XML isn’t the only reason SOAP is considered verbose and heavy compared to REST. It’s also
the way SOAP messages are composed. Standard SOAP API requests and responses appear as
an enveloped message that consists of four elements with specific functions for each one.
Envelope is the core and essential element of every message, which begins and concludes
messages with its tags, enveloping it, hence the name.

Header (optional) determines the specifics, extra requirements for the message, e.g.
authentication.

Body includes the request or response.

Fault (optional) shows all data about any errors that could emerge throughout the API request
and response.
SOAP extensibility with WS standard protocols

That said, SOAP itself provides basic structural elements of the message. But it doesn’t dictate
what goes into headers and bodies. Basically, you can customize these contents as appropriate.

But as web applications generally solve common sets of problems, after the SOAP release, the
main protocol has been augmented by numerous standard protocols that specify how you do
things. All these protocols are usually marked WS-(protocol name), e.g. WS-Security, WS-
ReliableMessaging. They were contributed by different organizations, including Microsoft, IBM,
OASIS, and others.

Standard protocols cover multiple areas and facets of SOAP use:

  Security

 Messaging

 Transactions

 Metadata, etc.

The cool thing about these protocols is that you can choose which of those you use. This is
usually described as SOAP extensibility. For instance, if you need your financial transactions to
be secure, you can apply WS-Atomic Transaction that are ACID-compliant.

ACID compliance

ACID stands for Atomicity, Consistency, Isolation, and Durability, which is an enterprise-grade
transaction quality and one of the reasons why SOAP is still used when exchanging sensitive
information in enterprise architectures.

ACID compliance means that transactions meet the following requirements:

Atomicity. Multiple connected transactions either work as a single unit or don’t work at all.
Sometimes this is called an all-or-none approach. This set of transactions is compared to an
atom, which consists of multiple tightly connected elements.

Consistency. If some part of a transaction fails, the system rolls back to its initial state.

Isolation. Transactions are independent of each other.

Durability. Even if the system fails, completed transactions remain.

If you use WS-Atomic Transaction, which is another standard protocol, you’ll be able to achieve
ACID-compliance.

Web Service Description Language (WSDL) document

One of the major features of SOAP APIs is that they almost always use a WSDL document.
Simply put, a WSDL document is an XML description of a web service. It acts as a guideline of
how to communicate with a web service, defining the endpoints and describing all processes that
could be performed by the exposed applications. These may include data types being used inside
the SOAP messages and all actions available via the web service. Thus, a WSDL file serves as a
signed contract between a client and a server.

Transfer protocols: HTTP, TCP, SMTP, FTP, and more

In layman terms, a transfer protocol is a set of rules and commands used to transfer data over the
internet. There are low-level protocols like IPv4, which simply delivers data packets from one
point to another. There are higher transfer layers, like TCP, which ensures that data is indeed
delivered. And, finally, there are application-level protocols that are used by web browsers to
communicate with web servers, but don’t take charge of the connection itself.

SOAP supports a variety of transfer protocols, both high- and low-level ones. For instance,
SOAP allows for messaging via TCP (Transaction Control Protocol), a low-level data exchange
method that works between ports via an IP network. You can go for the SMTP (Simple Mail
Transfer Protocol) option, which is a communication protocol for electronic mail transmission,
FTP (File Transfer Protocol), and any other transfer method that supports text data exchange.

Does it make any sense to send data using other protocols than HTTP/HTTPS? In most cases, it
doesn’t. SOAP was primarily designed to work with HTTP. But there may be scenarios, such as
security constraints, server requirements, solution architectures, or simply speed that will benefit
from this SOAP versatility.

SOAP WS-Security

SOAP is appreciated for its ability to integrate the WS-Security feature. This set of protocols
determines how to implement security inside the transactions and suggests data privacy and
integrity. Also, it allows for encryption and cryptographic signing.

What WS-Security does is allow your messages to be encrypted not only by HTTPS (which
already contains encryption), but also on the message level, having authentication data in the
header element. It’s needed to make sure that if your data travels out of HTTPS when it reaches
the server, it can only be read by the correct process inside this server, rather than the correct
server itself. As there can be some data preprocessing happening on the server side before the
message reaches its designated process.
Vittorio Bertocci, a Microsoft principal program manager, explained how WS-Security works
using a naked motorcyclist metaphor.

Imagine your message as a naked motorcyclist. To reach the destination, he can drive through a
transparent tunnel and hope that nobody sees him (HTTP). Or he can drive through an opaque
tunnel. In this case, while nobody sees him when he’s inside the tunnel, to reach the final
destination, he still must ride across some streets (HTTPS is an opaque tunnel, obviously). And
finally, he can just wear clothes and a helmet to feel completely secure (WS-Security).

This message-level security is why financial organizations and other corporate users opt for
SOAP.
SOAP stateful and stateless messaging

The beginning of the 21st century is remembered for the internet boom. Thousands of internet-
driven companies were emerging and millions of users were accessing the web every day. Now
imagine that a single server starts receiving thousands of requests from users (clients)
simultaneously. And if this resource does something more complex than show walls of text,
things can get slow. For instance, if users check the upcoming flights schedule and must drill
down to each flight detail, the server must be aware of what’s happening with the client, right?

It appears that you can handle this situation in two ways: using stateful and stateless operations.
And SOAP supports both.

Stateful means that the server keeps the information that it receives from a client across multiple
requests. For instance, first it memorizes the flight dates that you’re looking for and then
provides information on the pricing after the second request. This allows you to chain messages
together, making the server aware of the previous requests. Stateful messaging may be crucial in
operations involving multiple parties and complex transactions, e.g. bank operations or flight
booking. But still, it’s really heavy to a server.

Stateless communication means that each message contains enough information about the state
of the client so that a server doesn’t have to be bothered with it. Once the server returns
requested data, it forgets about the client. Each request is isolated from the previous one.
Stateless operations helped reduce server load and increase the speed of communication.

Stateful operations is one of the reasons SOAP is used for bank transactions and other data
exchange that requires chaining messages. More on SOAP use cases below.

Retry logic

When building a SOAP API, developers can integrate successful/Retry logic. To put it simply, if
something goes wrong, a requesting party gets the XML message with an error code and its
explanation. So a client-side developer understands the reason behind the failure and can tweak
the request to get a successful response. This feature adds some confidence to the development
process since you don’t have to manually search the problem. SOAP has a default specification
to establish the response format.

SOAP is versatile, powerful, and very standardized. But the thing is, sometimes you don’t need
the interface to be that rich. And SOAP has several disadvantages that easily tip the scale in
favor of REST for the majority of engineers and their organizations.

Some SOAP disadvantages to consider

Resource-consuming. Due to the larger size of an XML-file and a payload created by the
massive structure of a message, a SOAP API requires a larger bandwidth. Sometimes, this trade-
off isn’t worth dealing with. Simply put, it’s slow to process these strings of tags that XML
messages abound with.

Hard learning curve. Being protocol-based, building SOAP API servers requires knowledge
and understanding of all protocols you may use with it. Developers dealing with building these
types of APIs should dive deep into all processes inside the protocol with its highly restricted
rules.

Lacks flexibility. We’ve mentioned that a SOAP API serves as a strict contract between a client
and a server. With this in mind, this rigid SOAP schema requires additional effort to add or
remove the message properties on both sides of the communication, the server and the client. It
makes updating requests and responses a tedious process and slows down adoption.

How SOAP compares to REST

When describing SOAP, we must mention its main alternative – REST.

REST or representational state transfer is an architectural style, rather than a protocol. What this
means is that REST provides much more flexibility in terms of how you structure your message,
which format you use, and how the client and the server scale. SOAP, on the other hand, requires
tight coupling between client and server. If either side changes something, things go wrong,
hence its protocol nature.
REST was introduced in 2000 – it’s not much younger than SOAP – with an idea of making
servers care less about what’s happening on the client.

And here’s where one of the main differences between REST and SOAP begin.

As most engineers will tell you, SOAP and REST can’t be directly compared, but since both
approaches deal with solving a similar set of problems here’s a short breakdown
Stateful and stateless operations. REST is designed to be stateless; SOAP supports both
approaches.

Message structure. While the SOAP message is an ”envelope,” the REST message is on a
“postcard”: It has no extra wrappings or headers, or anything else that would alter its lightweight
nature.

Logic exposure. In contrast to SOAP that keeps its logic in the WSDL document, REST has its
alternative – a WADL document (or Web Application Description Language doc). It’s not as
common as WSDL, but sometimes it’s useful if you operate in a corporate environment and you
can’t easily contact people from the service side, requiring you to have some formal conventions
at hand.

Data formats. As we mentioned, SOAP is strictly XML. REST can operate with JSON, XML,
HTML, and other formats you like. But JSON (or JavaScript Object Notation) remains the most
popular.

Transfer protocols. SOAP is flexible in terms of transfer protocols to accommodate for multiple
scenarios. REST is solely focused on HTTP/HTTPS exchange. There may be some exceptions if
you map HTTP methods of exchange (GET, POST PUT, DELETE, etc.) to, say, FTP methods.
But REST was designed with HTTP in mind.

Caching. Caching means storing some information on the client-side to avoid additional load on
the server. For instance, you may cache non-dynamic content like images to load them faster on
the client-side and avoid requesting a server to do it every time you visit a resource. REST
allows you to cache data on the HTTP level. If you want to implement SOAP-caching, you have
to configure an additional cache module. Generally, REST is more cache-friendly.

Message size. The absence of the overhead text and code blocks in the plain JSON file as
compared to bulky XML in SOAP results in substantial size reduction. That is to say, a modest
RESTful API’s JSON file is easier and faster to process and transfer.
Learning curve. RESTful architecture is straightforward and simple to attain. SOAP requires a
much deeper understanding of standards and additional WS protocols. On top of that, the
engineering community that deals with REST is larger. So, you may expect to find answers to
problems much faster.

Error-handling. In contrast to a SOAP API where specification allows for returning the Retry
XML message with error code and its explanation, a REST API leaves less room for
transparency. REST mainly provides two options: The answer may contain the error code
without any explanation. This is a default feature. On the other hand, technology allows for the
manual prescription of error object along with its code.

Security. A REST API uses Secure Sockets Layer (or SSL) along with HTTPS on top of HTTP,
having a simple transport mechanism as the encryption method. HTTPS coverage acts as a shield
for data security. And SSL security protocol is applied over an HTTPS connection to verify
REST APIs calls. With SOAP you can also use SSL, including TCP-messaging, on top of the
message-level security.

SOAP Use Cases

Considering these differences, it gets obvious why web messaging is mostly done with REST. To
wrap things up, let’s define the cases when SOAP is still the major technology.

Highly standardized operations: billing, navigation, facilities. All use cases where you have
to eliminate any kind of misinterpretation are a good fit for SOAP communication. Usually,
these systems have strict contracts with clearly defined logic that can be described with a WSDL
document.

Bank transactions and payment systems. When you need your transactions to always be
reliable and non-reachable by third parties, SOAP has multiple benefits to consider. First, it’s the
level of security with ACID compliance and WS-Security protocols. Additionally, this set of use
cases usually requires stateful messaging, i.e. using chained transactions that aren’t isolated one
from another. Since payment systems may have multiple parties involved in a single operation,
SOAP allows for better coordination of their behavior.

Flight booking systems. Since flight booking usually involves multiple parties, some providers
from this industry still rely on SOAP to handle stateful and chained messaging.

Non-HTTP messaging and legacy environments. If the server requirements and existing
systems leverage communication protocols besides HTTP, SOAP is the first option to look at.

This article is part of a series that covers various approaches to digital communication systems
and standards. You may also want to check out:
REST API Explained
What is an API?
Before we dive into REST API, let us first see what an API is. API stands for Application
Programming Interface and acts as a mediator between the users and the resources. Let us
understand this with an example. When you go to a restaurant, do you have access to its kitchen
to get the food you wish to eat? No. Instead, there is a waiter(mediator), with whom you(client)
place your order(request). The waiter, in turn, serves you the food(response) that he gets from the
kitchen(resource). So, the waiter in this example is an API.

What is a REST API?

Now, what makes an API a REST API? REST stands for Representational State Transfer. It is a
software architectural style and provides a set of guidelines to create an API. An API that
conforms to those guidelines is referred to as a REST API or sometimes, as RESTful API. The
RESTful APIs should conform to the following constraints:
1. A client-server architecture consisting of clients, servers, and resources, where the
requests are managed through HTTP.
2. Stateless client-server communication, that means a session establishment between
client and server is not required. Each request is a separate and independent request.
3. Cacheability, the client should be able to cache information, whenever possible.
4. A uniform interface between the components so that the information is transferred in a
standard form, regardless of how it is represented in the server.
5. Layered system architecture, a client may not be directly communicating to the server.
There may be one or more intermediaries.
6. Code on demand, response can contain executable code such as Java applets or
JavaScript code.
How REST APIs work?
REST APIs make use of HTTP protocol for communication between the client and the server. It
uses HTTP requests to implement the CRUD operations - POST, GET, PUT and DELETE.
The request to the server is composed of three main parts:
1. URI - Uniform Resource Indicator to locate resources.
 2. Headers - Carries meta-data associated with the request.
3. Payload - present in the POST and PUT requests and contains the data to be sent to the
server.
The response from the server is composed of the following parts:
1. Status code - tells the status of the request, whether it was successful or not using HTTP
response codes. For example, 200 for successful.
2. Status Message - tells the status in English Words. For example, "Successful".
3. Response Payload - present in the response to GET message. Contains the data
requested.
If we go back to our restaurant example, you have to tell the waiter if your order is "For here or
To Go". Your order will be delivered to you in the 'format' you requested. In the same way, you
can request a REST API to deliver the data in any format you need, like JSON, HTML, XML or
plain text.
Rest API Testing
What is API?

An Application Programming Interface (API) defines interaction between multiple softwares or

mixed hardware-software. API is a set of programming code that enables data transmission
between one software product and another. API also provides extension mechanisms so that
users can extend existing functionality in various. An API can be entirely custom, specific to a
component, or designed based on an industry-standard.

API lets a developer make a specific “call” or “request” in order to send or receive information.
JSON(JavaScript Object Notation) is used as an programming language to communicate. It can
also be used to make a defined action such as updating or deleting data.

There are four basic request methods that can be made with API:

1. GET – Gathers the data

2. PUT – Updates the data

3. POST – Creates the data

 4. DELETE – Deletes the data

Example: An API delivers a user response to a system and sends the system’s response back to a
user. User clicks on “Add to Cart” button and API tells the website user added a product to a
cart; the website puts the product in user cart, and user cart is updated.

Some of the API Testing Tools

 Rapid API

 Rest Assured

 POSTMAN

 SoapUI

 JMeter

What is API testing?

API testing is a type of software testing, which make sure API is returning correct response as
per the expected response. It performs verification directly at the API level. It is a part of
integration testing that determines whether the APIs meet the expectations of functionality,
reliability, performance, and security.

Why API testing is needed?

 Investigating an app at API level would be tough so it’s better to do it at first

 Core functionalities of an API can be test

 Consumes less time than GUI functional testing

 Test data is mostly derived as JSON or XML format.

 Language Independent

 Easily integrated with GUI testing

Why a Checklist for API Testing is Important

An API checklist is important because:

 It Improves Test Coverage – API specifications allows tester to detect errors at an early
stage before getting into bigger problems.

 It’s more Cost-Effective – API testing requires less coding, which becomes a faster and
more affordable process.

 It provides stronger security – APIs are designed to remove common vulnerabilities, so

it provides more protection for your application if we follow an API security checklist.

 It’s Language Independent – By exchanging data via JSON or XML, user can select
any language for API testing.

 It Integrates simply with GUI – An API is highly integral when performing functional
GUI testing.

Types of Tests to Perform on Your APIs

 Validation Testing – This testing process occurs at the end of the development cycle to
validate whether the API’s basic parts and functions are correct or not.

 UI Testing – UI API testing examines the user interface. UI testing focuses on the
interface experience those ties into the API to verify the user experience is per the
expected result.

 Security Testing – Security tests main aim is to cover any vulnerability, threat or risk
within the API so that malicious attacks can be prevented. Security testing can identify all
possible loopholes and API weaknesses that can potentially result in a loss of
information, revenue and reputation.
  Load Testing – Load testing reviews the API performance for specific load, by adding
number of user’s activity into the API. User can examine how well the API behaves with
a spike of users accessing the API.

REST API

REST stands for REpresentational State Transfer. It is an architectural style that defines a set of
rules in order to create Web Services. In a client-server communication, REST suggests to create
an object of the data requested by the client and send values of that object in response to the user.
Just like any regular website, REST API’s use HTTP for communication. The data can be sent or
received in the form of JSON or XML.

For example, if a user is requesting for a movie in Noida at a certain place and time, then you can
create an object on the server-side.

Principles which REST API Follows

 Client-Server: In client-server architecture the client and the server should be separate
from each other and allowed to evolve individually. This enhances the portability across
multiple platforms as well as the scalability of the server components.
  Stateless: REST APIs are stateless, meaning history of any request or response or not
saved. Once the request is sent it closes the connection and establishes the new
connection to give the response.

 Cache: For better performance, applications are often made cacheable which saves the
processing time. This is done by labelling the response from the server as cacheable. If
the response is defined as cacheable, then the client cache can reuse the response data for
equivalent responses in the future.

 Uniform Interface: To separate client from server is by having a uniform interface that
allows independent changes into the application without having the application’s
services, or models and actions, tightly coupled to the API layer itself.

 Layered System: REST APIs have different layers of their architecture working together
to build a hierarchy which helps to create a more scalable and modular application.

 Code on Demand: This is an optional constraint and is used the least. Code on Demand
allows code or applets to be transmitted via the API for use within the application.

Parts of REST API:

A REST request is made up of the following parts:

 An HTTP verb that describes what action should be taken

 A Uniform Resource Locator (URL) that defines the location of the request

 HTTP headers that provide information to the server about the request

 A request body that provides further details for the request (this can be sometimes empty)

Here are the most common HTTP verbs:

 A GET request fetches a record from a database

  A POST request adds a new record to a database

 A PUT request replaces a record with a new one

 A PATCH request replaces part of a record with new information

 A DELETE request removes a record from a database

API Security: The Complete Guide

What is API Security?

An Application Programming Interface (API) allows software applications to interact with each
other. It is a fundamental part of modern software patterns, such as microservices architectures.

API security is the process of protecting APIs from attacks. Because APIs are very commonly
used, and because they enable access to sensitive software functions and data, they are becoming
a primary target for attackers.

API security is a key component of modern web application security. APIs may have
vulnerabilities like broken authentication and authorization, lack of rate limiting, and code
injection. Organizations must regularly test APIs to identify vulnerabilities, and address these
vulnerabilities using security best practices. This article presents several methods and tools for
API security testing, and a range of best practices that can help you secure your APIs.

This is part of an extensive series of guides about application security

In this article, you will learn:

 OWASP API Top 10 Security Threats
o Broken Object-Level Authorization
o Broken User Authentication
o Excessive Data Exposure
o Lack of Resources and Rate Limiting
o Broken Function-Level Authorization
o Mass Assignment
o Security Misconfiguration
o Injection
o Improper Asset Management
o Insufficient Logging and Monitoring
 REST API Security vs SOAP Security
 GraphQL Security
 Methods Of API Security Testing
o Test for Parameter Tampering
o Test for Command Injection
o Test for API Input Fuzzing
o Test for Unhandled HTTP Methods
 Top API Security Open Source Tools
o Postman
o Swagger
o JMeter
o SoapUI
o Karate
o Fiddler
 API Security Best Practices
o Identify Vulnerabilities
o Leverage OAuth
o Encrypt Data
o Use Rate Limiting and Throttling
o Use a Service Mesh
 o Adopt a Zero-trust Philosophy
 API Security with Bright
OWASP API Top 10 Security Threats

The increase of API-related security threats in recent years has prompted the Open Web
Application Security Project (OWASP) to release the API Security Top 10, which helps raise
awareness of the most serious API security issues affecting organizations These are:

API1:2019: Broken Object-Level Authorization

APIs often expose endpoints handling object identifiers. Any function that accepts a user input
and uses it to access a data source can create a Level Access Control issue, widening the attack
surface. You should carry out object-level authorization checks for all such functions.

API2:2019: Broken User Authentication

Attackers often take advantage of incorrectly applied authentication mechanisms. They may
compromise an authentication token or exploit flaws in implementation to pose as another user,
on a one-time basis or permanently. If the system’s ability to identify the client/user is
compromised, so is the overall API’s security.

API3:2019: Excessive Data Exposure

Developers often rely on the client side to filter the data before displaying it to the user. This can
create serious security issues—data must always be filtered at the server side, and only the
relevant information should be delivered to the client side.

API4:2019: Lack of Resources and Rate Limiting

APIs often don’t restrict the number or size of resources that the client/user can request. This can
impact the performance of the API server, resulting in Denial of Service (DoS), and exposing
authentication vulnerabilities, enabling brute force attacks.
API5:2019: Broken Function-Level Authorization

Authorization flaws often result from overly complex access control policies, or if there is no
clear separation between regular and administrative functions. Attackers can exploit these
vulnerabilities to gain access to a user’s resources or perform administrative functions.

API6:2019: Mass Assignment

Mass assignment typically results from the binding of client-provided data (i.e. JSON) to a data
model based on an allowlist, without proper filtering of properties. Attackers can modify object
properties in a number of ways—they can explore API endpoints, read the documentation, guess
object properties, or provide additional properties through request payloads.

API7:2019: Security Misconfiguration

Security misconfiguration often results from inadequate default configurations, ad-hoc or

incomplete configurations, misconfigured HTTP headers or inappropriate HTTP methods,
insufficiently restrictive Cross-Origin Resource Sharing (CORS), open cloud storage, or error
messages that contain sensitive information.

API8:2019: Injection

Injection flaws (including SQL injection, NoSQL injection, and command injection) involve data
that is sent to an interpreter from an untrusted source via a command or query. Attackers can
send malicious data to trick the interpreter into executing dangerous commands, or allow the
attacker to access data without the necessary authorization.

API9:2019: Improper Asset Management

Compared to traditional web applications, APIs typically expose more endpoints and thus require
structured, up-to-date documentation. Issues such as exposed debug endpoints and deprecated
API versions can increase the attack surface. This can be mitigated by creating an inventory of
deployed API versions and properly configured hosts.
API10:2019: Insufficient Logging and Monitoring

Attackers can take advantage of insufficient logging and monitoring, as well as ineffective or
lacking incident response integration, to persist in a system, deepen their hold and extract or
destroy more data. It typically takes over 200 days to detect a persistent threat, and breaches are
usually discovered by an external party—highlighting the critical importance of effective API
monitoring.

REST API Security vs SOAP Security

There are two main architectural styles used in modern APIs:

 SOAP—a highly structured message protocol that supports multiple low-level protocols.
 REST—a simpler approach to APIs using HTTP/S as the transport protocol, and typically
using JSON format for data transfer.

Both types of APIs support HTTP requests and responses and Secure Sockets Layer (SSL), but
the similarity ends there.

SOAP API security

 SOAP offers extensions to the protocol that address security matters

 SOAP is based on W3C and OASIS recommendations, including SAML tokens, XML
encryption, and XML signatures.
 SOAP supports the Web Services (WS) specifications, which lets you use security
extensions like WS-Security, which provides enterprise-grade security for web services
 SOAP supports WS-ReliableMessaging which provides built-in error handling

REST API security

 REST APIs do not have any built-in security capabilities—security depends on the design
of the API itself.
 Security must be built in for data transmission, deployment, and interaction with clients
 REST APIs do not have built-in error handling and need to resend data when an error
occurs.
  A common architectural choice is to deploy REST APIs behind an API gateway. Clients
connect to the gateway, which acts as a proxy, not directly to the REST API. This allows
many security concerns to be addressed by the API gateway.

In conclusion, SOAP APIs are more secure by design, but REST APIs can be made secure,
depending on their implementation and the architecture selected.

GraphQL Security

GraphQL is a query language that describes how clients can request information via an
application programming interface (API). Developers can use GraphQL syntax to request
specific data and receive it from a single source or multiple sources. Once a client defines the
required data structure for a request, a server returns data using that exact structure.

Since clients can craft highly complex queries, the server must be ready to properly handle them.
The server should be able to handle abusive queries from malicious clients, as well as large
queries by legitimate clients. If the server does not handle these scenarios properly, the client
might take the server down.

Here are a several strategies that can help you mitigate GraphQL security risks:

 Timeout – a timeout can help you defend against large queries. It is the simplest strategy
because it does not require the server to know any details about incoming queries. The
server only needs to know the maximum time allowed per query.
 Maximum query depth – can help you prevent clients from abusing query depth.
Maximum query depth is the analysis of a query document’s abstract syntax tree (AST)
to determine what is acceptable. The GraphQL server can then use this depth to accept or
reject requests.
 Query complexity – query depth is not always enough to understand the scope of a
GraphQL query. This usually happens when certain schema fields are more complex to
compute than others. Query complexity can help you define the level of complexity of
these fields, and restrict queries that exceed a complexity threshold.
 Throttling – the above options can stop large queries, but they cannot stop clients that
make many medium-sized queries. For GraphQL, even a few queries could be too much
 to handle, if queries are expensive. You can determine the server time needed to complete
each type of query, and use this estimation to throttle queries.
Methods Of API Security Testing

You can use the following methods to manually test your APIs for security vulnerabilities.

Test for Parameter Tampering

In most cases, parameters sent through API requests can be easily tampered with. For example,
by manipulating parameters, attackers can change the amount of a purchase and receive products
for free, or trick an API into providing sensitive data that is not authorized for the user’s
account.

Parameter tampering is often performed using hidden form fields. You can test for the presence
of hidden fields using the browser element inspector. If you find a hidden field, experiment with
different values and see how your API reacts.

Test for Command Injection

To test if your API is vulnerable to command injection attacks, try injecting operating system
commands in API inputs. Use operating system commands appropriate to the operating system
running your API server. It is recommended to use a harmless operating system command which
you can observe on the server—for example, a reboot command.

For example, if your API displays content via a URL, you can append an operating system
command to the end of the URL to see if the command is executed on the server:

https://vulnerablesite.com/view?name=userfile.txt;restart

Test for API Input Fuzzing

Fuzzing means providing random data to the API until you discover a functional or security
problem. You should look for indications that the API returned an error, processed inputs
incorrectly, or crashed.
For example, if your API accepts numerical inputs, you can try very large numbers, negative
numbers, or zero. If it accepts strings, you can try random SQL queries, system commands, or
arbitrary non-text characters.

Test for Unhandled HTTP Methods

Web applications that communicate using APIs may use various HTTP methods. These HTTP
methods are used to store, delete, or retrieve data. If the server doesn’t support the HTTP
method, you will usually get an error. However, this is not always the case. If the HTTP method
is unsupported on the server side, this creates a security vulnerability.

It is easy to test if HTTP methods are supported on the server side, by making a HEAD request
to an API endpoint that requires authentication. Try all the common HTTP methods—POST,
GET, PUT, PATCH, DELETE, etc.

Learn more in our guide to API security testing

Top Open Source API Testing Tools

Securing production APIs, especially those that have a regular development and release process,
requires automated tools. The following open source tools can help you design security-related
test cases, run them against API endpoints, and remediate issues you discover. They can also
discover business logic vulnerabilities, which can also be an opening for attackers.

Postman

Postman is an API development platform. Its key features include:

 Automating manual API tests

 Integrating tests into the CI/CD pipeline
  Simulating expected behavior of API endpoints and responses
 Checking API performance and response times
 Enables collaboration between developers with built-in version control
Swagger

Swagger is an open source toolkit that can help you create RESTful APIs. Its enables two API
development styles:

 Top-down API design, letting you build an API in Swagger and then generate code from
specifications
 Bottom-up API design, in which Swagger takes existing code and generates
documentation about API operations, parameters and outputs
JMeter

JMeter is a load testing tool, which can also be used for security testing. Key features include:
  Inputting CSV files and using them for load testing—this lets you perform tests with
different values to simulate risky scenarios and cyber attacks.
 Embedding API tests into the build process with Jenkins
 Advanced performance testing, with the ability to replay test results
SoapUI

Soap UI is a popular API functional testing tool. Its key features include:

 A large library of functional testing elements that let you automate API tests
 Fully customizable, provides source code so you can build your own features
 Easy drag and drop interface to create tests
 Lets you reuse existing load test or security scans for functional tests
 In the pro package, lets you perform data-driven testing, simulating how users work with
the API using spreadsheets or databases
Karate

Karate DSL is a Java API testing tool using the behavior-driven development (BDD) approach.
Its key features include:
  Writing BDD for APIs with ready-made step definitions
 Generates standard Java reports
 Does not require Java knowledge to write tests for Java-based APIs
 Enables multi-threaded execution
 Supports switching configuration between staging and production
Fiddler

Fiddler is a tool that monitors and replays HTTP requests, with an API testing extension for
.NET, Java, Ruby, and other popular frameworks. Its key features include:

 Debugging requests from any type of client—including Windows, MacOs, Linux, and
mobile devices
 Tests cookies, cache, and headers in client-server communication
 Provides a convenient UI for grouping and organizing API requests
 Creates mock requests and responses with no code changes
API Security Best Practices

Use the following best practices to improve security for your APIs.
Identify Vulnerabilities

The only way to effectively secure an API is to understand which parts of the API lifecycle are
insecure. This can be complex, especially if your organization operates a large number of APIs.
It is important to consider the entire API lifecycle—the API must be treated as a software
artifact, which goes through all the stages of a software product, from planning through
development, testing, staging, and production.
Leverage OAuth

One of the most important aspects of API security is access control for authentication and
authorization. A powerful tool for controlling API access is OAuth—a token-based
authentication framework that allows third-party services to access information without exposing
user credentials.

Encrypt Data

All data managed by an API, especially personally identifiable information (PII) or other
sensitive data protected by compliance standards and regulations must be encrypted. Implement
encryption at rest, to ensure attackers who compromise your API server cannot make use of it,
and encryption in transit using Transport Layer Security (TLS). Require signatures to ensure that
only authorized users can decrypt and modify data provided by your API.

Use Rate Limiting and Throttling

As APIs become popular, they become more valuable to attackers. APIs are now a prime target
for denial of service (DoS) attacks. Set rate limits on the method and frequency of API calls to
prevent DoS attacks, and protect against peak traffic, which can affect performance and security.
Rate limiting can also balance access and availability by regulating user connections.

Use a Service Mesh

Like API gateways, service mesh technology applies different layers of management and control
when routing requests from one service to the next. A service mesh optimizes the way these
moving parts work together, including correct authentication, access control and other security
measures.

As the use of microservices increases, service meshes are especially important. API management
is shifting to the service communication layer, and service meshes can provide automation and
security for large deployments with multiple APIs.
Adopt a Zero-trust Philosophy

Traditionally, networks had a perimeter and elements “inside” it were trusted, while elements
“outside” were not. Networks are no longer that simple, with insider threats becoming prevalent,
and legitimate users often connecting from outside the network perimeter. This is especially true
for public APIs with users from all over the world, accessing internal software components and
sensitive data.

A zero trust philosophy shifts the security focus from location to specific users, assets, and
resources. It can help you ensure that APIs always authenticate users and applications (whether
inside or outside the perimeter), provides the least privileges they actually need to perform their
roles, and closely monitors for anomalous behavior.

Test Your APIs with Dynamic Application Security Testing (DAST)

Bright has been built from the ground up with a dev first approach to test your web applications,
with a specific focus on API security testing.

With support for a wide range of API architectures, test your legacy and modern applications,
including REST API, SOAP and GraphQL.

To compliment DevOps and CI/CD, Bright empowers developers to detect and fix vulnerabilities
on every build, reducing the reliance on manual testing by leveraging multiple discovery
methods:

 HAR files
 OpenAPI (Swagger) files
 Postman Collections

Start detecting the technical OWASP API Top 10 and more, seamlessly integrated across your
pipelines via:

 Bright Rest API

 Convenient CLI for developers
 Common DevOps tools like CircleCI, Jenkins, JIRA, GitHub, Azure DevOps, and more