https://naveenautomationlabs.

com/tag/restassured/

What happens when you type a URL in the browser and press enter?

https://medium.com/@maneesha.wijesinghe1/what-happens-when-you-type-an-url-in-the-browser-
and-press-enter-bb0aa2449c1a

http codes :

https://www.restapitutorial.com/httpstatuscodes.html

2xx Success
This class of status code indicates that the client's request was successfully received, understood, and
accepted.

Wikipedia
This class of status codes indicates the action requested by the client was received, understood,
accepted and processed successfully.
200 OK

201 Created

202 Accepted

203 Non-Authoritative Information

204 No Content

205 Reset Content

206 Partial Content

207 Multi-Status (WebDAV)

208 Already Reported (WebDAV)

https://www.guru99.com/rest-api-interview-question-answers.html

https://www.softwaretestingmaterial.com/api-testing-interview-questions/
https://www.katalon.com/resources-center/blog/web-api-testing-interview-questions/

https://career.guru99.com/top-20-questions-on-api-testing/

https://www.softwaretestinghelp.com/api-testing-interview-questions-and-answers/

What is an API?
API is the acronym for Application Programming Interface. It is a software interface
that allows two applications to interact with each other without any user
intervention.

What is a Web Service?

A Web service is a collection of open protocols and standards which are widely
used for exchanging data between systems or applications.

 Web service is a collection of open source protocols and standards used for
exchanging data between systems or applications whereas API is a software
interface that allows two applications to interact with each other without
any user involvement.
 Web service is used for REST, SOAP and XML-RPC for communication while
API is used for any style of communication.
 Web service supports only HTTP protocol whereas API supports
HTTP/HTTPS protocol.
 Web service supports XML while API supports XML and JSON.
 All Web services are APIs but all APIs are not web services.
  A microservice is an architectural design that separates

portions of a (usually monolithic) application into small, self-

containing services.

By definition, this means an API is usually a portion of a

microservice, allowing for interaction with the microservice itself.

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

In simple words, API stands for Application Programming Interface. API

acts as an interface between two software applications and allows the
two software applications to communicate with each other. API is a
collection of software functions that can be executed by another
software program

3. What are the common API Testing Types?

API testing typically involves the following practices:

 Unit testing
 Functional testing
 Load testing
 Runtime/ Error Detection
 Security testing
 UI testing
 Interoperability and WS Compliance testing
 Penetration testing
 Fuzz testing

Learn more on API Testing Types

10. What are the advantages of API Testing?
 API Testing is time effective when compared to GUI Testing. API
test automation requires less code so it can provide faster and
better test coverage.
 API Testing helps us to reduce the testing cost. With API Testing
we can find minor bugs before the GUI Testing. These minor bugs
will become bigger during GUI Testing. So finding those bugs in
the API Testing will be cost-effective to the Company.
 API Testing is language independent.
 API Testing is quite helpful in testing Core Functionality. We can
test the APIs without a user interface. In GUI Testing, we need to
wait until the application is available to test the core
functionalities.
 API Testing helps us to reduce the risks.

11. What exactly needs to be verified in API

Testing?
Basically, on API Testing, we send a request to the API with the known
data and we analyze the response.
1. Data accuracy
2. HTTP status codes
3. Response time
3. Error codes in case API return any errors
4. Authorization checks
5. Non-functional testing such as performance testing, security testing

.16. What are the main challenges faced in API

testing?
Some of the challenges we face while doing API testing are as follows

 Selecting proper parameters and its combinations

 Categorizing the parameters properly
  Proper call sequencing is required as this may lead to inadequate
coverage in testing
 Verifying and validating the output
 Due to the absence of GUI, it is quite difficult to provide input
values

17. What are the types of bugs we face when

performing API testing?
Issues observed when performing API testing are

 Stress, performance, and security issues

 Duplicate or missing functionality
 Reliability issues
 Improper messaging
 Incompatible error handling mechanism
 Multi-threaded issues
 Improper errors

18. How is UI testing is not similar to API testing?

UI (User Interface) testing is to test the graphical interface part of the
application. Its main focus is to test the look and feel of an application.
On the other hand, API testing enables the communication between
two different software systems. Its main focus is in the business layer
of the application.

19. Name some most commonly used HTTP

methods?
Some of the HTTP methods are

GET: It enables you to retrieve data from a server

POST: It enables you to add data to an existing file or resource in a
server
PUT: It lets you replace an existing file or resource in a server
DELETE: It lets you delete data from a server
PATCH: It is used to apply partial modifications to a resource
OPTIONS: It is used to describe the communication options for the
target resource
HEAD: It asks for a response identical to that of a GET request, but
without the response body

20. Can you use GET request instead of PUT to

create a resource?
No, GET request only allows read only rights. It enables you to retrieve
data from a server but not create a resource. PUT or POST methods
should be used to create a resource.

21. What is the difference between PUT and POST

methods?
PUT and POST methods are sometimes confused in regards to when
each should be used. Using POST request, our intent is to create a new
object on the server whereas with PUT request, our intent is to replace
an object by another object.

POST should be used when the client sends the page to the server and
then the server lets the client know where it put it. PUT should be used
when the client specifies the location of the page

Don’t Miss:

 30+ Postman Interview Questions

5. What are the core components of an HTTP request?

An HTTP request includes five key elements:

 HTTP methods – Set of request methods to perform desired

action for a given resource (GET, PUT, POST, DELETE)
 Uniform Resource Identifier (URI) – Describes the resource
 HTTP Version, (example- HTTP v1.1)
 Request Headers, (example- Content-type : application/json,
Content-Length : 511)
  Payload – It is basically a Request Body which includes message
content.

6. State The Core Components of an HTTP Response?

Every HTTP response contains four key elements.

 Status/Response Code – These are response codes issued by a

server to a client’s request. For example, 404 means Page Not
Found, and 200 means Response is OK.
 HTTP Version – describes HTTP version, for example-HTTP v1.1.
 Response Header – Includes information for the HTTP response
message. For example, Content-type, Content-length, date,
status and server type.
 Response Body – It contains the data that was requested by a
client to server.

20. What is the purpose of status code 304?

It means NOT MODIFIED. It is used to reduce network bandwidth

usage in case of conditional GET requests. Response body should
be empty. Headers should have date, location etc.

26. Where are query parameters stored in a GET request?

Query parameters are stored in the URL in a GET request.

27. How can we access a Postman variable?

We can access a Postman variable by entering the variable name as

{{var}}

28. What is the HTTP response code for a POST request with
incorrect parameters?

400 Bad Request is an ideal response code for request with incorrect
parameters.

6. What is different between REST API and RESTful API?

REST (Representation State Transfer) API: It is basically an architectural
style that makes productive use of existing technology and protocols of the
web. It is a set of rules that developers need to follow when they develop
their API or services that are scalable. It is used with HTTP protocol using its
verbs such as GET, DELETE, POST, PUT.
RESTful API: It is simply referred to as web services executing such as
architecture.
REST API RESTful API
REST is an architectural pattern
used for creating web services. RESTful API is used to implement that pattern.
The data format of REST is based The data format of RESTful is based on JSON,
on HTTP. HTTP, and Text.
Working of URL is based on Working of RESTful is based on REST
request and response. applications.
It is more user-friendly and highly
adaptable to all business
enterprises and IT. It is too flexible.
It is required to develop APIs that It simply follows REST infrastructure that
allow interaction among clients provides interoperability among different
and servers. systems on the whole network.

7. What are the advantages of using Rest in Web API?

REST is very important and beneficial in Web API because of the following
reasons:

 It allows less data transfer between client and server.

 It is easy to use and lightweight.
 It provides more flexibility.
 It also handles and controls various types of calls, returning various data
formats.
 It is considered best for using it in mobile apps because it makes less data
transfer between client and server.
 It uses simple HTTP calls for inter-machine communication rather than using
more complex options like CORBA, COM+, SOAP, or RPC.
8. What is REST and SOAP? What is different between them?
REST (Representational State Transfer): It is a new and improved form
of web service. It describes the architectural style of networked systems. It
does not require greater bandwidth when requests are sent to the server. It
just includes JSON message. For example:
{"city":"Mumbai","state":"Maharashtra"}
SOAP (Simple Object Access Protocol): It is a simple and lightweight
protocol that is generally used for exchanging structured and typed
information on the Web. It works mostly with HTTP and RPC (Remote
Procedure Call). This protocol is mainly used for B2B applications one can
define a data contract with it. SOAP messages are heavier in content and
therefore use greater bandwidth.

For example:

<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope"
SOAP-ENV:encodingStyle=" http://www.w3.org/2001/12/soap-encoding">
<soap:Body>
<Demo.guru99WebService xmlns="http://tempuri.org/">
<EmployeeID>int</EmployeeID>
</Demo.guru99WebService>
</soap:Body>
</SOAP-ENV:Envelope>
REST SOAP
It is basically an architectural
pattern. It is basically a messaging protocol.
It usually works with various text
formats such as plain text, HTML,
JSON, XML, etc. It only works with XML formats.
It has some specifications for both stateless and
It is totally stateless. stateful implementation.
Its performance is faster as
compared to SOAP. Its performance is slower as compared to REST.
It uses WSDL (Web Service Description
It uses XML and JSON to send and Language) for communication among
receive data. consumers or users and providers.
SOAP includes built-in error handling for
REST has to resend transfer communications errors using WS-
whenever it determines any errors. ReliableMessaging specification.
It calls services by calling RPC (Remote
It calls services using the URL path. Procedure Call) method.

11. Web API supports which protocol?

Web API generally supports only HTTP protocol.

12. Which of the following Open-source libraries is used by WEB API for JSON
serialization?

Json.NET library is generally used by Web API for JSON serialization.

13. What is XML and JSON?
XML (Extensible Markup Language):
 It is especially designed to store and transport data.
 It is similar to HTML but is more flexible than HTML because it allows users to
create their own custom tags.
 It is used for representing structured information such as documents, data,
configuration, etc.

JSON (JavaScript Object Notation):

 It is a lightweight format designed to store and transport data.
 It is easier to understand and is a standard text-based format used for
representing structured data based on JavaScript object syntax.
 It is faster and easier to use

34. Difference between HTTP GET vs HTTP Post?

HTTP (HyperText Transfer Protocol) simply manages request-response
between client and server. It works as a request-response protocol between
client and server.

HTTP GET: This method is used to get information or data from a respective
server at a specified URL.

Example:
GET/RegisterStudent.asp?user=value1&pass=value2

HTTP POST: This method is used to send data or information to respective

servers.

Example:
POST/RegisterStudent.asp HTTP/1.1
Host: www.guru99.com
user=value1&pass=value2
HTTP GET HTTP POST
Its parameters are included in
the URL. Its parameters are included in the body.
This method is used to request
data from specified resources This method is used to send data to a server to
and has no other effect. create or update resources.
It carries request parameters in the message body
It carries a request parameter that make it a more secure way of sending data or
appended in the URL string. information from the client to the server.
Request method using GET is Request method using POST is not cacheable.
HTTP GET HTTP POST

cacheable.
GET requests are less safe than
POST. Post request is safer than GET.
There is a restriction on data
type in GET method and only There are no restrictions on data type in this
ASCII characters are allowed. method and binary data is also allowed.
Data is visible to everyone in the Data is not displayed in the URL. It is present in
URL. the payload.

REST API Basic Interview Questions

1. What do you understand by RESTful Web Services?

RESTful web services are services that follow REST architecture. REST stands
for Representational State Transfer and uses HTTP protocol (web protocol)
for implementation. These services are lightweight, provide maintainability,
scalability, support communication among multiple applications that are
developed using different programming languages. They provide means of
accessing resources present at server required for the client via the web
browser by means of request headers, request body, response body, status
codes, etc.

2. What is a REST Resource?

Every content in the REST architecture is considered a resource. The

resource is analogous to the object in the object-oriented programming
world. They can either be represented as text files, HTML pages, images, or
any other dynamic data.

 The REST Server provides access to these resources whereas the REST client
consumes (accesses and modifies) these resources. Every resource is
identified globally by means of a URI.
3. What is URI?
Uniform Resource Identifier is the full form of URI which is used for
identifying each resource of the REST architecture. URI is of the format:
<protocol>://<service-name>/<ResourceType>/<ResourceID>

There are 2 types of URI:

 URN: Uniform Resource Name identifies the resource by means of a name
that is both unique and persistent.
o URN doesn’t always specify where to locate the resource on the
internet. They are used as templates that are used by other parsers to
identify the resource.
o These follow the urn scheme and usually prefixed with urn:. Examples
include
 urn:isbn:1234567890 is used for identification of book based on
the ISBN number in a library application.
 urn:mpeg:mpeg7:schema:2001 is the default namespace rules for
metadata of MPEG-7 video.
o Whenever a URN identifies a document, they are easily translated into
a URL by using “resolver” after which the document can be
downloaded.
 URL: Uniform Resource Locator has the information regarding fetching of a
resource from its location.
o Examples include:
 http://abc.com/samplePage.html
 ftp://sampleServer.com/sampleFile.zip
 file:///home/interviewbit/sampleFile.txt
o URLs start with a protocol (like ftp, http etc) and they have the
information of the network hostname (sampleServer.com) and the path
to the document(/samplePage.html). It can also have query
parameters.
5. What is the concept of statelessness in REST?

The REST architecture is designed in such a way that the client state is not
maintained on the server. This is known as statelessness. The context is
provided by the client to the server using which the server processes the
client’s request. The session on the server is identified by the session
identifier sent by the client.
6. What do you understand by JAX-RS?

As the name itself stands (JAX-RS= Java API for RESTful Web Services) is a
Java-based specification defined by JEE for the implementation of RESTful
services. The JAX-RS library makes usage of annotations from Java 5
onwards to simplify the process of web services development. The latest
version is 3.0 which was released in June 2020. This specification also
provides necessary support to create REST clients.

7. What are HTTP Status codes?

These are the standard codes that refer to the predefined status of the task
at the server. Following are the status codes formats available:

 1xx - represents informational responses

 2xx - represents successful responses
 3xx - represents redirects
 4xx - represents client errors
 5xx - represents server errors

Most commonly used status codes are:

 200 - success/OK
  201 - CREATED - used in POST or PUT methods.
 304 - NOT MODIFIED - used in conditional GET requests to reduce the
bandwidth use of the network. Here, the body of the response sent should
be empty.
 400 - BAD REQUEST - This can be due to validation errors or missing input
data.
 401 - FORBIDDEN - sent when the user does not have access (or is
forbidden) to the resource.
 404 - NOT FOUND - Resource method is not available.
 500 - INTERNAL SERVER ERROR - server threw some exceptions while
running the method.
 502 - BAD GATEWAY - Server was not able to get the response from another
upstream server.
8. What are the HTTP Methods?

HTTP Methods are also known as HTTP Verbs. They form a major portion of
uniform interface restriction followed by the REST that specifies what action
has to be followed to get the requested resource. Below are some examples
of HTTP Methods:

 GET: This is used for fetching details from the server and is basically a read-
only operation.
 POST: This method is used for the creation of new resources on the server.
 PUT: This method is used to update the old/existing resource on the server
or to replace the resource.
 DELETE: This method is used to delete the resource on the server.
 PATCH: This is used for modifying the resource on the server.
 OPTIONS: This fetches the list of supported options of resources present on
the server.
The POST, GET, PUT, DELETE corresponds to the create, read, update,
delete operations which are most commonly called CRUD Operations.
GET, HEAD, OPTIONS are safe and idempotent methods
whereas PUT and DELETE methods are only idempotent.
POST and PATCH methods are neither safe nor
idempotent.

9. Can you tell the disadvantages of RESTful web services?

The disadvantages are:

 As the services follow the idea of statelessness, it is not possible to maintain

sessions. (Session simulation responsibility lies on the client-side to pass the
session id)
 REST does not impose security restrictions inherently. It inherits the security
measures of the protocols implementing it. Hence, care must be chosen to
implement security measures like integrating SSL/TLS based
authentications, etc.
10. Define Messaging in terms of RESTful web services.

The technique of sending a message from the REST client to the REST
server in the form of an HTTP request and the server responding back with
the response as HTTP Response is called Messaging. The messages
contained constitute the data and the metadata about the message.
REST API Experienced Interview Questions
11. Differentiate between SOAP and REST?
SOAP REST
SOAP - Simple Object Access
Protocol REST - Representational State Transfer
SOAP is a protocol used to REST is an architectural design pattern for
implement web services. developing web services
SOAP cannot use REST as it is a REST architecture can have SOAP protocol as
protocol. part of the implementation.
SOAP specifies standards that are REST defines standards but they need not be
meant to be followed strictly. strictly followed.
SOAP REST
SOAP client is more tightly The REST client is more flexible like a browser
coupled to the server which is and does not depend on how the server is
similar to desktop applications developed unless it follows the protocols required
having strict contracts. for establishing communication.
SOAP supports only XML
transmission between the client REST supports data of multiple formats like XML,
and the server. JSON, MIME, Text, etc.
SOAP reads are not cacheable. REST read requests can be cached.
SOAP uses service interfaces for
exposing the resource logic. REST uses URI to expose the resource logic.
SOAP is slower. REST is faster.
Since SOAP is a protocol, it REST only inherits the security measures based
defines its own security measures. on what protocol it uses for the implementation.
SOAP is not commonly preferred,
but they are used in cases which REST is commonly preferred by developers these
require stateful data transfer and days as it provides more scalability and
more reliability. maintainability.

12. While creating URI for web services, what are the best practices that
needs to be followed?

Below is the list of best practices that need to be considered with designing
URI for web services:

 While defining resources, use plural nouns. Example: To identify user

resource, use the name “users” for that resource.
 While using the long name for resources, use underscore or hyphen. Avoid
using spaces between words. For example, to define authorized users
resource, the name can be “authorized_users” or “authorized-users”.
 The URI is case-insensitive, but as part of best practice, it is recommended
to use lower case only.
 While developing URI, the backward compatibility must be maintained once
it gets published. When the URI is updated, the older URI must be redirected
to the new one using the HTTP status code 300.
 Use appropriate HTTP methods like GET, PUT, DELETE, PATCH, etc. It is not
needed or recommended to use these method names in the URI. Example:
To get user details of a particular ID, use /users/{id} instead of /getUser
 Use the technique of forward slashing to indicate the hierarchy between the
resources and the collections. Example: To get the address of the user of a
particular id, we can use: /users/{id}/address
13. What are the best practices to develop RESTful web services?

RESTful web services use REST API as means of implementation using the
HTTP protocol. REST API is nothing but an application programming
interface that follows REST architectural constraints such as statelessness,
cacheability, maintainability, and scalability. It has become very popular
among the developer community due to its simplicity. Hence, it is very
important to develop safe and secure REST APIs that follow good
conventions. Below are some best practices for developing REST APIs:

 Since REST supports multiple data formats, it is however good practice to

develop REST APIs that accept and responds with JSON data format
whenever possible. This is because a majority of the client and server
technologies have inbuilt support to read and parse JSON objects with ease,
thereby making JSON the standard object notation.
o To ensure that the application responds using JSON data format, the
response header should have Content-Type set to
as application/JSON, this is because certain HTTP clients look at the
value of this response header to parse the objects appropriately.
o To ensure that the request sends the data in JSON format, again the
Content-Type must be set to application/JSON on the request header.
 While naming the resource endpoints, ensure to use plural nouns and not
verbs. The API endpoints should be clear, brief, easy to understand, and
informative. Using verbs in the resource name doesn’t contribute much
information because an HTTP request already has what the request is doing
in its HTTP method/verb. An appropriate HTTP verb should be used to
represent the task of the API endpoint.
o Below are the most commonly used HTTP methods to define the verb:
 GET - indicates get/retrieve the resource data
 POST - indicates create new resource data
 PUT - indicates update the existing resource data
 DELETE - indicates remove the resource data
 To represent the hierarchy of resources, use the nesting in the naming
convention of the endpoints. In case, you want to retrieve data of one object
residing in another object, the endpoint should reflect this to communicate
what is happening. For example, to get the address of an author, we can
use the GET method for the URI /authors/:id/address'
o Please ensure there are no more than 2 or 3 levels of nesting as the
name of the URI can become too long and unwieldy.
 Error Handling should be done gracefully by returning appropriate error
codes the application has encountered. REST has defined standard HTTP
Status codes that can be sent along with the response based on the
scenario.
o Error codes should also be accompanied by appropriate error
messages that can help the developers to take corrective actions.
However, the message should not be too elaborate as well which can
help the hacker to hack your application.
o Common status codes are:
 400 - Bad Request – client-side error - failed input validation.
  401 - Unauthorized – The user is not authenticated and hence
does not have authority to access the resource.
 403 - Forbidden – User is authenticated but is not authorized to
access the resource.
 404 - Not Found – The resource is not found.
 500 - Internal server error – This is a very generic server-side
error that is thrown when the server goes down. This shouldn’t
be returned by the programmer explicitly.
 502 - Bad Gateway – Server did not receive a valid response
from the upstream server.
 503 - Service Unavailable – Some unexpected things happened
on the server such as system failure, overload, etc.
 While retrieving huge resource data, it is advisable to include filtering and
pagination of the resources. This is because returning huge data all at once
can slow down the system and reduce the application performance. Hence,
filter some items reduces the data to some extent. Pagination of data is
done to ensure only some results are sent at a time. Doing this can increase
the server performance and reduce the burden of the server resources.
 Good security practices are a must while developing REST APIs. The client-
server communication must be private due to the nature of data sensitivity.
Hence, incorporating SSL/TLS becomes the most important step while
developing APIs as they facilitate establishing secure communication. SSL
certificates are easier to get and load on the server.
o Apart from the secure channels, we need to ensure that not everyone
should be able to access the resource. For example, normal users
should not access the data of admins or another user. Hence, role-
based access controls should be in place to make sure only the right
set of users can access the right set of data.
 Since REST supports the feature of caching, we can use this feature to
cache the data in order to improve the application performance. Caching is
done to avoid querying the database for a request repeated times. Caching
makes data retrieval fast. However, care must be taken to ensure that the
cache has updated data and not outdated ones. Frequent cache update
measures need to be incorporated. There are many cache providers like
Redis that can assist in caching.
 API Versioning: Versioning needs to be done in case we are planning to
make any changes with the existing endpoints. We do not want to break
communication between our application and the apps that consume our
application while we are working on the API release. The transition has to be
seamless. Semantic versioning can be followed. For example, 3.0.1
represents 3rd major version with the first patch. Usually, in the API
endpoints, we define /v1,/v2, etc at the beginning of the API path.
14. What are Idempotent methods? How is it relevant in RESTful web
services domain?

The meaning of idempotent is that even after calling a single request

multiple times, the outcome of the request should be the same. While
designing REST APIs, we need to keep in mind to develop idempotent APIs.
This is because the consumers can write client-side code which can result in
duplicate requests intentionally or not. Hence, fault-tolerant APIs need to be
designed so that they do not result in erroneous responses.

 Idempotent methods ensure that the responses to a request if called once

or ten times or more than that remain the same. This is equivalent to
adding any number with 0.
 REST provides idempotent methods automatically. GET, PUT, DELETE, HEAD,
OPTIONS, and TRACE are the idempotent HTTP methods. POST is not
idempotent.
o POST is not idempotent because POST APIs are usually used for
creating a new resource on the server. While calling POST methods N
times, there will be N new resources. This does not result in the same
outcome at a time.
o Methods like GET, OPTIONS, TRACE, and HEAD are idempotent
because they do not change the state of resources on the server.
They are meant for resource retrieval whenever called. They do not
result in write operations on the server thereby making it idempotent.
o PUT methods are generally used for updating the state of resources.
If you call PUT methods N times, the first request updates the
resource and the subsequent requests will be overwriting the same
resource again and again without changing anything. Hence, PUT
methods are idempotent.
o DELETE methods are said to be idempotent because when calling
them for N times, the first request results in successful deletion
(Status Code 200), and the next subsequent requests result in
nothing - Status Code 204. The response is different, but there is no
change of resources on the server-side.
 However, if you are attempting to delete the resource present,
at last, every time you hit the API, such as the
request DELETE /user/last which deletes the last user record,
then calling the request N times would delete N resources on
the server. This does not make DELETE idempotent. In such
cases, as part of good practices, it is advisable to use POST
requests.
15. What are the differences between REST and AJAX?
REST AJAX
REST- Representational State
Transfer AJAX - Asynchronous javascript and XML
REST has a URI for accessing AJAX uses XMLHttpRequest object to send
resources by means of a request- requests to the server and the response is
response pattern. interpreted by the Javascript code dynamically.
REST is an architectural pattern for
developing client-server AJAX is used for dynamic updation of UI without
communication systems. the need to reload the page.
REST requires the interaction AJAX supports asynchronous requests thereby
between client and server. eliminating the necessity of constant client-
REST AJAX
server interaction.

16. Can you tell what constitutes the core components of HTTP Request?

In REST, any HTTP Request has 5 main components, they are:

 Method/Verb − This part tells what methods the request operation

represents. Methods like GET, PUT, POST, DELETE, etc are some examples.
 URI − This part is used for uniquely identifying the resources on the server.
 HTTP Version − This part indicates what version of HTTP protocol you are
using. An example can be HTTP v1.1.
 Request Header − This part has the details of the request metadata such as
client type, the content format supported, message format, cache settings,
etc.
 Request Body − This part represents the actual message content to be sent
to the server.

 Request Body − This part represents the actual message content to be sent
to the server.

17. What constitutes the core components of HTTP Response?

HTTP Response has 4 components:

 Response Status Code − This represents the server response status code for
the requested resource. Example- 400 represents a client-side error, 200
represents a successful response.
 HTTP Version − Indicates the HTTP protocol version.
  Response Header − This part has the metadata of the response message.
Data can describe what is the content length, content type, response date,
what is server type, etc.
 Response Body − This part contains what is the actual resource/message
returned from the server.

18. Define Addressing in terms of RESTful Web Services.

Addressing is the process of locating a single/multiple resources that are

present on the server. This task is accomplished by making use of URI
(Uniform Resource Identifier). The general format of URI is

<protocol>://<application-name>/<type-of-resource>/<id-of-resource>
19. What are the differences between PUT and POST in REST?
PUT POST
PUT methods are used to request the server to store
the enclosed entity in request. In case, the request POST method is used to
does not exist, then new resource has to be created. request the server to store the
If the resource exists, then the resource should get enclosed entity in the request
updated. as a new resource.
The POST URI should indicate
The URI should have a resource identifier. the collection of the resource.
Example: PUT /users/{user-id} Example: POST /users

POST methods are not

PUT methods are idempotent. idempotent.
PUT is used when the client wants to modify a single
resource that is part of the collection. If a part of the POST methods are used to
resource has to be updated, then PATCH needs to be add a new resource to the
used. collection.
PUT POST
Responses are not cacheable
unless the response explicitly
The responses are not cached here despite the specifies Cache-Control fields
idempotency. in the header.
POST is used for CREATE
In general, PUT is used for UPDATE operations. operations.

20. What makes REST services to be easily scalable?

REST services follow the concept of statelessness which essentially means

no storing of any data across the requests on the server. This makes it
easier to scale horizontally because the servers need not communicate
much with each other while serving requests.

21. Based on what factors, you can decide which type of web services you
need to use - SOAP or REST?

REST services have gained popularity due to the nature of simplicity,

scalability, faster speed, improved performance, and multiple data format
support. But, SOAP has its own advantages too. Developers use SOAP
where the services require advanced security and reliability.

Following are the questions you need to ask to help you decide which
service can be used:

 Do you want to expose resource data or business logic?

o SOAP is commonly used for exposing business logic and REST for
exposing data.
 Does the client require a formal strict contract?
o If yes, SOAP provides strict contracts by using WSDL. Hence, SOAP is
preferred here.
 Does your service require support for multiple formats of data?
o If yes, REST supports multiple data formats which is why it is
preferred in this case.
 Does your service require AJAX call support?
o If yes, REST can be used as it provides the XMLHttpRequest.
 Does your service require both synchronous and asynchronous requests?
o SOAP has support for both sync/async operations.
o REST only supports synchronous calls.
 Does your service require statelessness?
o If yes, REST is suitable. If no, SOAP is preferred.
 Does your service require a high-security level?
o If yes, SOAP is preferred. REST inherits the security property based on
the underlying implementation of the protocol. Hence, it can’t be
preferred at all times.
  Does your service require support for transactions?
o If yes, SOAP is preferred as it is good in providing advanced support
for transaction management.
 What is the bandwidth/resource required?
o SOAP involves a lot of overhead while sending and receiving XML
data, hence it consumes a lot of bandwidth.
o REST makes use of less bandwidth for data transmission.
 Do you want services that are easy to develop, test, and maintain
frequently?
o REST is known for simplicity, hence it is preferred.
22. We can develop webservices using web sockets as well as REST. What
are the differences between these two?
REST Web Socket
REST follows stateless architecture, Web Socket APIs follow the stateful
meaning it won’t store any session-based protocol as it necessitates session-based
data. data storage.
The mode of communication is uni- The communication is bi-directional,
directional. At a time, only the server or communication can be done by both
the client will communicate. client or server at a time.
REST is based on the Request-Response Web Socket follows the full-duplex
Model. model.
Web sockets do not have any overhead
Every request will have sections like and hence suited for real-time
header, title, body, URL, etc. communication.
There will be only one TCP connection
For every HTTP request, a new TCP and then the client and server can start
connection is set up. communicating.
REST web services support both vertical Web socket-based services only support
and horizontal scaling. vertical scaling.
Web Sockets depend on the IP address
REST depends on HTTP methods to get the and port number of the system to get a
response. response.
Message transmission happens very
Communication is slower here. faster than REST API.
Memory/Buffers are not needed to store
data here. Memory is required to store data.

The request flow difference between the REST and Web Socket is shown
below:
23. Can we implement transport layer security (TLS) in REST?

Yes, we can. TLS does the task of encrypting the communication between
the REST client and the server and provides the means to authenticate the
server to the client. It is used for secure communication as it is the
successor of the Secure Socket Layer (SSL). HTTPS works well with both TLS
and SSL thereby making it effective while implementing RESTful web
services. One point to mention here is, the REST inherits the property of the
protocol it implements. So security measures are dependent on the protocol
REST implements.

24. Should we make the resources thread safe explicitly if they are made to
share across multiple clients?

There is no need to explicitly making the resources thread-safe because,

upon every request, new resource instances are created which makes them
thread-safe by default.

25. What is Payload in terms of RESTful web services?

Payload refers to the data passes in the request body. It is not the same as
the request parameters. The payload can be sent only in POST methods as
part of the request body.
26. Is it possible to send payload in the GET and DELETE methods?

No, the payload is not the same as the request parameters. Hence, it is not
possible to send payload data in these methods.

27. How can you test RESTful Web Services?

RESTful web services can be tested using various tools like Postman,
Swagger, etc. Postman provides a lot of features like sending requests to
endpoints and show the response which can be converted to JSON or XML
and also provides features to inspect request parameters like headers,
query parameters, and also the response headers. Swagger also provides
similar features like Postman and it provides the facility of documentation
of the endpoints too. We can also use tools like Jmeter for performance and
load testing of APIs.

28. What is the maximum payload size that can be sent in POST methods?

Theoretically, there is no restriction on the size of the payload that can be

sent. But one must remember that the greater the size of the payload, the
larger would be the bandwidth consumption and time taken to process the
request that can impact the server performance.

29. How does HTTP Basic Authentication work?

While implementing Basic Authentication as part of APIs, the user must

provide the username and password which is then concatenated by the
browser in the form of “username: password” and then perform base64
encoding on it. The encoded value is then sent as the value for the
“Authorization” header on every HTTP request from the browser. Since the
credentials are only encoded, it is advised to use this form when requests
are sent over HTTPS as they are not secure and can be intercepted by
anyone if secure protocols are not used.

30. What is the difference between idempotent and safe HTTP methods?
 Safe methods are those that do not change any resources internally. These
methods can be cached and can be retrieved without any effects on the
resource.
 Idempotent methods are those methods that do not change the responses
to the resources externally. They can be called multiple times without any
change in the responses.
According to restcookbook.com, the following is the table that describes
what methods are idempotent and what is safe.
HTTP Idempote Saf
Methods nt e
OPTIONS yes yes
GET yes yes
HEAD yes yes
PUT yes no
POST no no
DELETE yes no
PATCH no no

JAX-RS Interview Questions

31. What are the key features provided by JAX-RS API in Java EE?

JAX-RS stands for Java API for RESTful Web services. They are nothing but a
set of Java-based APIs that are provided in the Java EE which is useful in the
implementation and development of RESTful web services.

Features of JAX-RS are:

 POJO-based: The APIs in the JAX-RS is based on a certain set of

annotations, classes, and interfaces that are used with POJO (Plain Old Java
Object) to expose the services as web services.
 HTTP-based: The JAX-RS APIs are designed using HTTP as their base
protocol. They support the HTTP usage patterns and they provide the
corresponding mapping between the HTTP actions and the API classes.
 Format Independent: They can be used to work with a wide range of data
types that are supported by the HTTP body content.
 Container Independent: The APIs can be deployed in the Java EE
container or a servlet container such as Tomcat or they can also be plugged
into JAX-WS (Java API for XML-based web services) providers.
32. Define RESTful Root Resource Classes in the JAX-RS API?
 A resource class is nothing but a Java class that uses JAX-RS provided
annotations for implementing web resources.
 They are the POJOs that are annotated either with @Path or have at least
one method annotated with @Path, @GET, @POST, @DELETE, @PUT, etc.

Example:

import javax.ws.rs.Path;
/**
* InterviewBitService is a root resource class that is exposed at
'resource_service' path
*/
@Path('resource_service')
public class InterviewBitService {
// Defined methods
}
33. What do you understand by request method designator annotations?

They are the runtime annotations in the JAX-RS library that are applied to
Java methods. They correspond to the HTTP request methods that the
clients want to make. They are @GET, @POST, @PUT, @DELETE, @HEAD.

Usage Example:

import javax.ws.rs.Path;
/**
* InterviewBitService is a root resource class that is exposed at
'resource_service' path
*/
@Path('resource_service')
public class InterviewBitService {
@GET
public String getRESTQuestions() {
// some operations
}
}
34. How can the JAX-RS applications be configured?

JAX-RS applications have the root resource classes packaged in a war file.
There are 2 means of configuring JAX-RS applications.

1. Use @ApplicationPath annotation in a subclass

of javax.ws.rs.core.Application that is packaged in the WAR file.
2. Use the <servlet-mapping> tag inside the web.xml of the WAR. web.xml is
the deployment descriptor of the application where the mappings to the
servlets can be defined.
35. Is it possible to make asynchronous requests in JAX-RS?
Yes. the JAX-RS Client API provides a method
called Invocation.Builder.async() that is used for constructing client
requests that need to be executed asynchronously. Invoking a request
asynchronously does the task of returning the control to the caller by
returning with datatype java.util.concurrent.Future whose type is set to
return the service call type. Future objects are used because they have the
required methods to check whether the asynchronous calls have been
completed and if yes, then retrieve the responses. They also provide the
flexibility to cancel the request invocations and also check if the
cancellation has been successful.
Let us understand this with the help of a random example. We know that
the Future interface from the java.util.concurrent has the below functions
available:
package java.util.concurrent;
public interface Future<V> {
 // informs the executor to stop the thread execution
boolean cancel(boolean mayInterruptIfRunning);

// indicates whether the Future was cancelled or not

boolean isCancelled();

// indicates if the executor has completed the task

boolean isDone();

// gets the actual result from the process.

// This blocks the program execution until the result is ready.
V get() throws InterruptedException, ExecutionException;

// also gets actual result from the process but it throws

// the TimeoutException in case the result is not obtained before
specified timeout
V get(long timeout, TimeUnit unit)
throws InterruptedException, ExecutionException, TimeoutException;
}

Let us consider we have this function below which is used for processing 2
Ids parallelly.

public void processIds(String userId1, String questionId){

Client client = ClientBuilder.newClient();
Future<Response> futureResponse1 =
client.target("http://interviewbitserver.com/users/"+userId).request().async
().get();
Future<Order> futureResponse2 =
client.target("http://interviewbitserver.com/questions/"+questionId).request
().async().get(Question.class);

// block the process until complete

Response response1 = futureResponse1.get();
User userObject = response1.readEntity(User.class);
//Do processing of userObject

// Wait for 2 seconds before fetching record

try {
Question question = futureResponse2.get(2, TimeUnit.SECONDS);
//Do Processing of question
} catch (TimeoutException timeoutException ) {
//handle exceptions
}
return;
}
In the above example, we see that there are 2 separate requests getting
executed parallelly. For the first future object, we await
the javax.ws.rs.core.Response indefinitely using the get() method until we
get the response. For the second future object, we wait for the response
only for 2 seconds and if we do not get within 2 seconds, then the get()
method throws TimeoutException. We can also use the isDone() method or
isCancelled() method to find out whether the executors have completed or
cancelled.
36. List the key annotations that are present in the JAX-RS API?
 @Path - This specifies the relative URI path to the REST resource.
 @GET - This is a request method designator which is corresponding to the
HTTP GET requests. They process GET requests.
 @POST - This is a request method designator which is corresponding to the
HTTP POST requests. They process POST requests.
 @PUT - This is a request method designator which is corresponding to the
HTTP PUT requests. They process PUT requests.
 @DELETE - This is a request method designator which is corresponding to
the HTTP DELETE requests. They process DELETE requests.
 @HEAD - This is a request method designator which is corresponding to the
HTTP HEAD requests. They process HEAD requests.
 @PathParam - This is the URI path parameter that helps developers to
extract the parameters from the URI and use them in the resource
class/methods.
 @QueryParam - This is the URI query parameter that helps developers
extract the query parameters from the URI and use them in the resource
class/methods.
 @Produces - This specifies what MIME media types of the resource
representations are produced and sent to the client as a response.
 @Consumes - This specifies which MIME media types of the resource
representations are accepted or consumed by the server from the client.
Spring RESTful Web Services Interview Questions
37. Define RestTemplate in Spring.

The RestTemplate is the main class meant for the client-side access for
Spring-based RESTful services. The communication to the server is
accomplished using the REST constraints. This is similar to other template
classes such as JdbcTemplate, HibernateTemplate, etc provided by Spring.
The RestTemplate provides high-level implementation details for the HTTP
Methods like GET, POST, PUT, etc, and gives the methods to communicate
using the URI template, URI path params, request/response types, request
object, etc as part of arguments.

 Commonly used annotations like @GetMapping, @PostMapping, @PutMapping,

etc are provided by this class from Spring 4.3. Prior to that, Spring provided
(and still provides) @RequestMapping annotation to indicate what methods
were being used.
38. What is the use of @RequestMapping?
 The annotation is used for mapping requests to specific handler classes or
methods.
 In spring, all the incoming web request routing is handled by Dispatcher
Servlet. When it gets the request, it determines which controller is meant
for processing the request by means of request handlers. The Dispatcher
Servlet scans all the classes annotated with @Controller. The process of
routing requests depends on @RequestMapping annotations that are
declared inside the controller classes and their methods.
39. What are the differences between the annotations @Controller and
@RestController?
@Controller @RestController
Represents RESTful web service in
Mostly used traditional Spring MVC service. Spring.
It is used in case of RESTful web
It is mostly used in Spring MVC service where service that returns object values
model data needs to rendered using view. bound to response body.
If response values need to be converted The default behavior of the
through HttpMessageConverters and sent via @RestController needs to be written
response object, extra annotation on the response body because it is
@ResponseBody needs to be used on the class the combination of @Controller and
or the method handlers. @ResponseBody.
@RestController annotation has no
@Controller provides control and flexibility such flexibility and writes all the
over how the response needs to be sent. results to the response body.

40. What does the annotation @PathVariable do?

@PathVariable annotation is used for passing the parameter with the URL
that is required to get the data. Spring MVC provides support for URL
customization for data retrieval using @PathVariable annotation.

41. Is it necessary to keep Spring MVC in the classpath for developing

RESTful web services?
Yes. Spring MVC needs to be on the classpath of the application while
developing RESTful web services using Spring. This is because, the Spring
MVC provides the necessary annotations like @RestController,
@RequestBody, @PathVariable, etc. Hence the spring-mvc.jar needs to be
on the classpath or the corresponding Maven entry in the pom.xml.
42. Define HttpMessageConverter in terms of Spring REST?

HttpMessageConverter is a strategic interface that specified a converter for

conversion between HTTP Requests and responses. Spring REST uses the
HttpMessageConverter for converting responses to various data formats
like JSON, XML, etc. Spring makes use of the “Accept” header for
determining the type of content the client expects. Based on this, Spring
would find the registered message converter interface that is capable of
this conversion.
Conclusion
43. Conclusion

We have seen what are the most commonly asked questions on RESTful
web services during an interview. REST APIs have become a very important
tool in the software industry. Developing RESTful web services that are
scalable and easily maintainable is considered an art. As the industry
trends increase, the REST architecture would become more concrete and
the demand for developers who know the development of RESTful web
services would increase steadily.

https://www.interviewbit.com/rest-api-interview-questions/

18. What are major challenges faced in API testing?

If you can overcome the challenges in API Testing, you can be

confident in the API testing interview too. They are:

 Parameter Selection

 Parameter Combination

 Call sequencing

 Output verification and validation

 Another important challenge is providing input values,

which is very difficult as GUI is not available in this case.

23. What is API documentation?

The API documentation is a complete, accurate technical

writing giving instructions on how to effectively use and
integrate with an API. It is a compact reference manual that has
all the information needed to work with the API, and helps you
answer all the API testing questions with details on functions,
classes, return types, arguments, and also examples and
tutorials.

24. What are API documentation templates that are commonly

used?

There are several available API documentation templates help

to make the entire process simple and straightforward, which
could be answered in your API testing interview, such as:

 Swagger

 Miredot

 Slate

 FlatDoc

 API blueprint

 RestDoc

 Web service API specification

22. What kinds of bugs that API testing would often find?

 Missing or duplicate functionality

 Fails to handle error conditions gracefully

 Stress

 Reliability

 Security

 Unused flags
  Not implemented errors

 Inconsistent error handling

 Performance

18. What are major challenges faced in API testing?

If you can overcome the challenges in API Testing, you can be

confident in the API testing interview too. They are:

 Parameter Selection

 Parameter Combination

 Call sequencing

 Output verification and validation

 Another important challenge is providing input values,

which is very difficult as GUI is not available in this case.

19. What are the testing methods that come under API testing?

One of the most common Web API testing interview questions is

about the testing methods. They are:

 Unit testing and Functional testing

 Load testing to test the performance under load

 Discovery testing to list, create and delete the number of

calls documented in API

 Usability and Reliability testing to get consistent results

  Security and Penetration testing to validate all types of
authentication

 Automation testing to create and run scripts that require

regular API calls

 End to end Integration and Web UI testing

 API documentation testing to determine its efficiency and

effectiveness

20. Why is API testing considered as the most suitable form for
Automation testing?

API testing is now preferred over GUI testing and is considered

as most suitable because:

 It verifies all the functional paths of the system under test

very effectively.

 It provides the most stable interface.

 It is easier to maintain and provides fast feedback.

21. What are common API errors that often founded?

Not only API fundamental questions, the interviewer also

determine your knowledge and experience by asking about the
API errors in a Web API testing interview. So the most common
ones are:

 Missing module errors

 Documentation errors

 Parameter validation errors

  And some standard error expectations as if the result is
not so predicted then the occurrence of errors can be seen
and for the same warnings are specified in the form of a
message. There can be one or more warnings within an
individual module.

22. What kinds of bugs that API testing would often find?

 Missing or duplicate functionality

 Fails to handle error conditions gracefully

 Stress

 Reliability

 Security

 Unused flags

 Not implemented errors

 Inconsistent error handling

 Performance

 Multi-threading issues

 Improper errors

https://www.iteanz.com/api-interview-questions-and-answers/
https://mediatemple.net/community/products/dv/204644990/why-am-i-getting-a-
500-internal-server-error-message

What is a 500 Internal Server Error?

For every request that is sent to a server, there is an http status code that is
returned. These status codes will be returned as a 3 digit number (200, 403,
404, 500, 502, etc). Each of these numbers provide some indication as to
what type of issue is preventing your site from loading. The 5XX errors
indicate that a request has been sent to the server, but some technical issue
has prevented this request from being completed.

The 500 Internal Server Error in particular is a catch-all error message, given
when no more specific message is suitable. There can be a number of
causes for a 500 Internal Server Error to display in a web browser. Below is a
sample of what a 500 error message will look like.

COMMON CAUSES

Below are common troubleshooting steps that can be taken to resolve a 500
Internal Server Error:
 1. Check the error logs
2. Check the .htaccess file
3. Check your PHP resources
4. Check CGI/Perl scripts

CHECK THE ERROR LOGS!

With any error message, particularly one as broad as the 500 Internal Server
Error, you will first want to check any Apache and PHP error logs for your
server. These logs can provide valuable context related to any code failures or
other potential causes of a site failure. For information on where to find the
logs for your server, please see: Where are the access_log and error_log for
my server?

ERROR WITH AN .HTACCESS FILE

If you are using a .htaccess on your site, it may be interfering with the web
page you are trying to load into your

Troubleshooting an HTTP 500 internal server error is like solving a mystery.

You don't know what exactly happened or why it happened — all you know is
that something's wrong and you need to fix it.

To guide you through the hassle of troubleshooting the dreaded HTTP 500
internal server error, let's go over what it exactly means and its most common
causes and solutions.

Free Guide: How to Run a Technical SEO Audit

What is an HTTP 500 internal server error?

An HTTP 500 internal server error means your web server is

experiencing problems, but it can't pinpoint the specific error or its
root causes. When this happens, your website will serve up a
general internal server error web page to your site's visitors.

Here's what your 500 error page might look like in your browser:

How to Fix a 500 Internal Server Error

Unlike other server-side errors like a 502 code or a 503 code, a 500
internal server error is it doesn't immediately tell you what the problem is, nor
does it tell you how to fix it. If the error persists for too long on your site, it
could even negatively impact your SEO.

So, let's dive into a few potential causes of the error. Then, we'll present some
solutions so you can try to fix the issue.

Potential Causes of a 500 Internal Server Error

A 500 internal server error is, as the name implies, a general problem with the
website's server. More than likely, this means there's an issue or temporary
glitch with the website's programming.

Some potential causes of a 500 internal server error include:

 Corrupted or broken .htaccess file

 A permissions error

 Faulty third-party plugins or themes

 The PHP memory limit being exceeded

Fortunately, there are a few effective solutions for fixing most of these
problems.

If You're Trying to Load a Page with a 500 Internal Server Error:

1. Refresh the page.

This might seem obvious, but if it's a temporary loading issue, you might find
success if you refresh the page. Before trying anything else in this list, reload
the page and see what happens.

2. Come back later.

Since the error is on the server side, I'm willing to bet the website owners are
working as quickly as possible to resolve the issue. Give it a few minutes or
up to an hour or so, and then reload the URL and see if the development team
has fixed the issue.

3. Delete your browser's cookies.

If clearing the browser history doesn't work, you might try deleting your
browser's cookies. If the cookies are associated with the error-prone
webpage, deleting the cookies might help reload the page.

4. Paste your URL into the website "Down for Everyone or Just Me."

Head to downforeveryoneorjustme.com and paste in the URL where

you're seeing the internal server error. You'll either be told that the website is
only down for you, or that the website is down for everyone.
If it's a problem with your server, this should help assuage any concerns that
it's an issue with your own computer.

If the 500 Internal Server Error is on Your Own Website:

1. Deactivate a plugin or theme.

Newly activated software, add-ons, or third-party scripts might be conflicting

with your current server configuration. To determine this, try (carefully)
deactivating or uninstalling your software add-ons one at a time to identify
what exactly is causing the internal server error.

If you run a WordPress website, this is easy to do with plugins. From your
dashboard, choose Plugins > Installed Plugins, then deactivate the
first plugin. If the error resolves, you know this plugin is part of the issue.
Reactivate the first plugin, then repeat this deactivate-reactivate process one
at a time for all plugins to determine which ones are causing your error.
You might find that having fewer active plugins on your site helps things run
more smoothly.

Alternatively, if you just upgraded your software, your current plugins or

themes might not be compatible with the new upgrade. Deactivating plugins or
themes one at a time until the error disappears is the best way to find the root
cause of your problem.

2. Use a plugin like WP Debugging to identify the issue.

If your site is powered by WordPress and you're comfortable with WordPress

debugging processes, consider installing a plugin to help you identify the
issue with your server.

The debug plugin WP Debugging, for instance, helps you figure out
exactly what's wrong with your site, which will result in a speedier fix.
 Image Source

3. Ensure your PHP setup is configured correctly.

If the issue is related to a PHP timeout, consider creating timeout rules or

error handling in your script to resolve the issue. Here's a full list of
php.ini directives to configure your PHP setup.
Additionally, wrong permissions on a file or folder that has a script, like a PHP
or CGI script, won't allow the script to run. Check your permissions and make
sure you set them correctly on your server.

4. Check the code for your site's .htaccess file.

Incorrect coding or improper structure with your .htaccess file could be the
reason you're seeing the 500 internal error. The .htaccess file helps you
manage how long resources should be stored in a browser's cache. Try
editing the file if you're seeing a 500 internal server error.
To locate your .htaccess file, access your website files through a file manager
like cPanel or via FTP/SFTP. The file will probably be located in
your public_html directory. There's a good chance your server will hide this
file from view by default and you'll need to toggle hidden files on to see it.
 Image Source

Coding errors in .htaccess and custom scripts can also cause an HTTP 500
internal server error.

5. Ensure your new software is installed correctly.

Finally, check to see if your recently installed or upgraded software actually

failed to install or upgrade. To refresh your software, check the vendor's
website for instructions.
Last Resort: Ask a Server Administrator for Help

If troubleshooting popular software problems or debugging server-side scripts

doesn't fix your HTTP 500 internal server error, you should read about the
most common causes for this type of issue in your server's documentation —
an HTTP 500 internal server error can occur in different operating systems for
a multitude of reasons.

You can also ask your service provider to access your error logs and find
evidence for the root cause of your problem.

Internal server errors are irritating because they're unhelpful — it's basically
the web server's way of saying, "Eh, I'm not sure." Hopefully, one of the above
steps will resolve the problem so you can get back to life as usual.