Web API testing Terminologies
What is basically a Web Applications?
Applications that can be accessed over a network or the internet
without installing them on your
machine.
A
Web Application is a software application that is deployed to a Web Server like IIS/Tomcat.
This means the application is installed onto a computer and users access the
application via a Web Browser.
Since we use/access Web applications with a GUI, we are unaware
of the Http request/different type of Http requests being made.
HTML is the specification for the Web Page so the Browser knows how to display it to the user
When we test HTTP APIs we have to understand the details of HTTP
requests.
The requests that the Browser sends to the Web Server are HTTP requests.
HTTP requests are a way of sending messages between machines over the Internet. Think of HTTP as the format of the message that Browser and Web Server send to each other.
Whats an API?
"An API is designed to be used for systems and
applications to communicate, whereas a GUI is designed for humans to use."
What's a HTTP or Web APIs?
API is an interface provided to other applications to provide
access to an application features.
An HTTP based API is often called a Web API since they are used
to access Web Applications which are deployed to Servers accessible over the
Internet.
Applications which are accessed via HTTP APIs are often called
Web Services.
Mobile Applications often use Web Services and REST APIs to
communicate with servers to implement their functionality.
API
Architecture
API calls Collection include mainly three things:
HTTP headers
HTTP Request
(POST,GET,PUT,DELETE )
Status Code/ Response
Code
HTTP headers - HTTP headers are always depended
on your application, Mainly 2 Headers are used
Authorization - A token included with requests to identify the
requester. This header has to be included in all requests other than the login
request.
Content-Type - A standard MIME type describes the format of
object data.
Content –type in most of the requests and responses will be application/json.
Content –type in most of the requests and responses will be application/json.
HTTP Request
- There are mainly four request, which we used frequently:
POST - Create Or Update data
PUT - Update data
GET - Retrieve data
DELETE – Delete data
Status
Code/Response Code - There are many status/response code, from them we can
verify the response.
200 - OK, The request was successful.
201 - Created, The request was successful
and data was created.
204 - No Content, The response is empty.
400 - Bad Request, The request could not
be understood or was missing required parameters.
401 – Unauthorized, Authentication failed
or user does not have permissions for the requested operation.
403 - Forbidden, Access denied.
404 - Not Found, Data was not found.
405 - Method Not Allowed, Requested
method is not supported for the specified resource.
500 - Internal Server Error.
503 - Service Unavailable, The service is
temporary unavailable.
What Is an HTTP
Request?
HTTP stands for Hypertext Transfer Protocol and is a way of
sending messages to software
on another computer over the Internet or over a Network.
An HTTP request is sent to a specific URL and consists of:
• a VERB specifying the type of request e.g. GET, POST, PUT,
DELETE
• A set of HTTP Headers. The headers specify information such as
the type of Browser, type of content in the message, and what type of response is
accepted in return.
• A body, or payload in the request, representing the
information sent to, or from, the Web Application.
Not all
HTTP messages can have payloads: POST and PUT can have payloads, GET and DELETE cannot.
URL can be broken down into the form:
"scheme://host/resource"
• scheme - http
• host - Blogger.com
• resource - apps/mocktracks/projectsjson.php
Also I haven’t used a
query because this endpoint doesn’t need one.
A larger form for a URL is:
"scheme://host:port/resource?query#fragment"
The query is a way of passing parameters in the URL to the
endpoint
The query is the set of parameters which are key, value pairs
delimited by ‘&’ e.g. q=test
and start=10 (“start” is a key, and “10” is the value for that
key).
When working with APIs it is mainly the scheme, host, port and
query that you will use.
GET requests do not have a body, and just consist of the Verb,
URL and the Headers.
POST requests can have a payload body
When working with a Web Application or HTTP API the typical HTTP
Verbs used are:
• GET, to read information.
• POST, to create information.
• PUT, to amend or create information.
• DELETE, to delete information, this is rarely used for Browser
accessed applications, but often used for HTTP APIs.
simple grouping for HTTP Status Codes is:
• 1xx - Informational
• 2xx - Success e.g. 200 Success
• 3xx - Redirection e.g. 302 Temporary Redirect
• 4xx - Client Error e.g. 400 Bad Request, 404 Not Found
• 5xx - Server Error e.g. 500 Internal Server Error
What Are HTTP Headers?
HTTP messages have the Verb and URL, followed by a set of headers, and then the optional payload.
POST http://www.Blogger.com/apps/mocks/reflection.php HTTP/1.1
Host:
Content-Type: application/json
X-APPLICATION_KEY: asse-234j-were
Accept: application/json
{"action":"Learn"}
The headers are a set of meta data for the message.
The above HTTP message example has four headers:
• Host
• Content-Type
• Accept
• X-APPLICATION_KEY
The Host header defines the destination server domain name.
The Content-Type header tells the server that the content of this message is JSON.
The Accept header tells the server that the client (application sending the message) will only accept response payloads represented in JSON.
What Is Authentication?
When we send a message to a server we might need to be authenticated i.e. authorised to send a message and receive a response. For many Web Applications you authenticate yourself in the application by logging in with
a username and password. The same is true for Web Services or HTTP APIs.
If you are not authenticated and try to send a message to a server then you are likely to receive a response from the server with a 4xx status code e.g.
• 401 Unauthorized
• 403 Forbidden
There are many ways to authenticate HTTP requests for HTTP APIs.
Some common approaches you might encounter are:
• Custom Headers
• Basic Authentication Headers
• Session Cookies
Some HTTP APIs require Custom Headers e.g.
POST http://www.Blogger.com/apps/mocks/reflection.php HTTP/1.1
X-APPLICATION_KEY: asse-234j-were
Here the X-APPLICATION-KEY header has a secret value which authenticates the request.
The API uses XML/JSON as its Payload format.
What Are Payloads?
A Payload is the body of the HTTP request or response.
When browsing the Web, the Browser usually receives an HTML payload. This is the web page that you see rendered in the Browser.
Typically when working with an HTTP API we will send and receive
JSON or XML payloads.
What Is JSON?
JSON stands for JavaScript Object Notation and is a text
representation that is also valid JavaScript code.
JSON can be thought of as a hierarchical set of key/value pairs
where the value can be:
• Object - delimited by { and }.
• Array - delimited by [ and ].
• String - delimited by " and ".
• Integer
An array is a list of objects or key/value pairs.
The keys are String values e.g. “projects”, “project”, “id”,
etc.
{
"projects": {
"project": [
{
"id": 1,
"name": "Ajay",
"position": 1,
"description": "QA",
"state": "active",
"created-at": "2017-06-27T12:25:26+01:00",
"updated-at": "2017-06-27T12:25:26+01:00"
}
]
}
}
REST stands for Representational State Transfer, and while it
has a formal definition, it very often means
that the API will respond to HTTP verbs as commands.
e.g.
• GET, to read information.
• POST, to create information.
• PUT, to amend information.
• DELETE, to delete information.
Any data retrieved by a GET would be in the body of the HTTP response, and any data in a PUT
or POST request to create and amend data would be in the body of the HTTP request.
General HTTP REST Return Codes
When we issue REST calls, there are a few HTTP return codes we
would expect to see:
• 200 (OK) when we GET to retrieve information
• 401 (Unauthorized) when we try to access information without
the correct credentials
e.g. without logging in
• 404 (Not Found) when we GET information that does not exist,
or POST, PUT DELETE to
an end point that does not exist
• 201 (created) when we use POST to create a new entity
• 409 (Already Exists) we we try to create an existing entity
• 302 (Redirect) when we successfully issue a request, the
system may redirect us somewhere else, e.g POST a login request and be redirected to
the user dashboard
Also that the input and output from the API are designed for
creation and consumption by code - hence the use of formats like JSON and XML.
How to Identify whether the application GUI is using API or not?
We can simulate the GUI actions using proxy, so that every
action call will be directed through proxy.
We can see that different requests POST and GET, etc are used,
and none of the URLs are .xml URLs, so different parts of the application are
being called, the API is not used by the GUI.
API testing is strongly
connected with Back-end/Database testing, you may have brief knowledge of SQL
queries.
Fuzzers
HTTP debug proxies are used as Fuzzers to create Data
Use of Fuzzers in Debug proxy like OWASP ZAP(Zed Attack Proxy)
Use foxyproxy in chrome to set the proxy running
Some of the proxy tools, e.g. BurpSuite and OWASP ZAP, have
‘fuzzers’. I can use a Fuzzer to iterate over values, in much the same way as I fed a file of
values into the commands from Bash or the command line. It easier to use the Fuzzer GUI than
use the command line to create lots of data.
Why we use DTO's?
To avoid the domain objects to be
exposed. where in only some of the properties of the Domain objects will only
be exposed.
Web API's should never expose the Domain objects
How to Stack trace when a javascript object is executed?
View
the stack trace that caused a request
When
a JavaScript statement causes a resource to be requested, hover over the Initiator column to
view the stack trace leading up to the request.
Comments
Post a Comment