Analogy 1

Quite simple....
Rest Api is the dumb slave of the clever boss, who never asks questions who never don't
know what to do with the information that he is having.... May be we call him a loyal slave....

Analogy 2
We can call rest api as a fellow smuggler who don't know the value of the cocoin that he is
having, Some smugglers don't know what they are transferring between countries but still
doing their jobs Like a boss......

What is an API
API (Application Programming Interface) is a set of functions that allow interaction between
two software application. It enables data exchange between two systems written in same or
different language.

API's are of two types

SOAP is Simple Object Access Protocol, which is a messaging protocol that communicate
between two application using HTTP(Hyper Text Transfer Protocol) and uses XML for data
exchange.

REST is Representational State Transfer, it uses HTTP requests to communicate and

API Testing:
It covers both SOAP and Rest endpoint testing. It can be done using Postman, SoapUI, Rest
Template, jersey,Jmeter even using Rest Assured(which is a tool to test a Rest API )

Rest API Testing:

Rest Assured:
This is a tool/Framework to test Rest API which is used with Java Language. It can be easily
used with maven/Gradle and JUnit/TestNG.

e.g
Maven dependency
<dependency>
<groupId>io.rest-assured</groupId>
<artifactId>rest-assured</artifactId>
<version>3.0.2</version>
<scope>test</scope>
</dependency

Gradle

testCompile 'io.rest-assured:rest-assured:3.0.2'

Example
@Test
public void example() {

given().
when().
get("http:www.example.com/test").
then().
assertThat().
statusCode(200).
and().
contentType(ContentType.JSON).
and().
header("Content-Length",equalTo("230"));
}

Since, REST Assured is a tool to test restful APIs, test automation services companies
perform manual testing using POSTMAN or REST Client before automating them through
REST Assured.

What is API?

Application Programming Interface, or API, is a shorthand for that.The intermediary layer

API Testing : API testing involves testing the APIs directly, including their functionality,
dependability, performance, and security. API testing, which is a type of integration testing,
quickly and efficiently tests the build architecture's logic.
Rest API Testing: Representational State Transfer (REST) is an architectural design that
establishes standards for communication across web-based http://systems.An API known as
a REST API adheres to a set of guidelines so that applications and services can communicate
with one another.REST APIs, often known as RESTful APIs because they are restricted to
REST design, offer a flexible way to access online services without requiring a lot of
processing power.

An open-source automation method for testing RESTful APIs for web apps is known as REST
API testing. It is frequently used to test web applications that employ JSON and XML. All
methods, including GET, PUT, POST, PATCH, and DELETE are compatible.

Rest-Assured API Testing: Rest-Assured is a Java-based library that is used to test RESTful
Web Services. This library behaves like a headless Client to access REST webservices. To send
to the Restful server, we can design HTTP requests that are incredibly customizable.This
enables us to test a large range of Request combinations, which in turn allows us to test
various combinations of the essential business logic.

The validation of HTTP Responses that are received from the server is another feature
offered by the Rest-Assured library.For instance, we can check the response's Status code,
Status message, Headers, and even Body.Rest-Assured is a very adaptable library that may
be used for testing as a result.

I had a sort o "Big Picture" moment about REST a while back. I had been aware of the term
for quite some time, but I just thought of it as a more straightforward way to implement
APIs directly over HTTP.

But REST is more than that, and there seems to be almost religious debate about it out
there. A lot of very experienced people react to the idea of doing complicated transactional
logic over REST as some kind of absurdity and point out all sorts of examples where REST
does not seem to work. The "RESTafarians" maintain that a REST approach is just the way
things should work on the web, and anything can be done if you think about it the right
way.

To understand REST you have to think carefully about the big picture of state and how it is
transferred between parts of a distributed process. But most programmers can't see the big
picture, because the entire point of the IT revolution over the last 40 years has been to
centralize state in business processes.

Realtime inventory, online banking, ERP - we take this for granted that this is just the only
way a business can run. We expect to always be able to connect to a remote database that
is the final authority on the state of any given aspect of a business. These days we expect
online banking show your available balance adjusted immediately after you use your debit
card.
But think back, if you are old enough, the the days of yore. If I recall, we managed to have
an Industrial Revolution, win a few wars, and send a man to the moon without the benefit of
databases and networks. How was it done? Paper. Forms. Carbon copies, rubber stamps,
signatures, sequence numbers.

That's what REST is. A high tech version of an old-school bureaucracy. Paper messages that
represent state and can be moved from one clerk to another.

Think carefully about what that paper message is in a business process. It is a self contained
REpresentation of State that can be Transferred between agents in the system. You could
have the Pony Express deliver it for you, the transport does not matter. The transporters do
not need to know anything about the content of your message. There is however a "receipt"
if needed (certified mail) so you can verify your message was accepted.

The piece of paper itself is a self contained message to change state. Nothing happens until
it is moved from one entity to another. You walk into your bank. You fill out a deposit slip.
You hand the deposit slip to the teller, along with your cash. The teller accepts your deposit
slip and gives you a paper receipt. The teller takes the stack of deposit slips to a clerk who
processes each one by noting the change on a ledger and using a big rubber stamp to mark
PROCESSED on each so that the slip could never accidentally be handled again.

The person is the client. The piece of paper is the content of the HTTP request. Giving the
paper to someone else is the HTTP request to the server. You know immediately if your
request was accepted or not, though it is up to you to keep your own state as to what that
means to you, the client (balance your checkbook).

Think of much more complicated examples, and you realize that everything was once done
in a RESTful manner, on paper. Clearing checks between banks.. Trading stocks, you name it.
Civilization existed before there were databases to provide transactions and realtime state.

Now you may wonder why in the world it would make sense to model distributed systems
on the bureaucracy from the movie Brazil, but the fact is, bureaucracy scales. Horizontally. It
can deal with disconnected systems and asynchronous messages and entities that are not
under central control and not even trusting of each other.

If you think about it, any real world business process can be modeled in a RESTful way with
enough clients, servers and the right pieces of "paper."

(And the fact is, in the real world, very few real systems maintain centralized state for long. A
tangled mess of REST behavior ends up eventually appearing when reality sets in and it
becomes apparent that offline transactions and exception handling are needed, one
database is not enough, etc.)
Am I making any sense on this? I know people will have examples that they think won't
work, I want to try and see if I can prove myself right on this, so please add your comments.