REST Interview Questions & Answers for Freshers and Experienced

A web service is a collection of open protocols and standards used for exchanging data between applications or systems. Software applications written in various programming languages and running on various platforms can use web services to exchange data over computer networks like the Internet in a manner similar to inter-process communication on a single computer.

REST stands for Representational State Transfer. It relies on a stateless, client-server, cacheable communications protocol -- and in virtually all cases, the HTTP protocol is used.
It is an architecture style for designing networked applications.It is a lightweight alternative to Web Services and RPC. REST design operations are self-contained, and each request carries with it (transfers) all the information (state) that the server needs in order to complete it.

Following well known HTTP methods are commonly used in REST based architecture:
GET : Provides a read only access to a resource.
PUT : Used to create a new resource.
DELETE : Ued to remove a resource.
POST : Used to update a existing resource or create a new resource.
OPTIONS : Used to get the supported operations on a resource.

Much like Web Services, a REST service is:
Platform-independent (you don't care if the server is Unix, the client is a Mac, or anything else),
Language-independent (C# can talk to Java, etc.),
Standards-based (runs on top of HTTP), and
Can easily be used in the presence of firewalls.
Like Web Services, REST offers no built-in security features, encryption, session management, QoS guarantees, etc. But also as with Web Services, these can be added by building on top of HTTP:

REST architecture treats every content as a resource. These resources can be text files, html pages, images, videos or dynamic business data. REST Server simply provides access to resources and REST client accesses and modifies the resources. Here each resource is identified by URIs/ global IDs.

PUT and DELETE operations are idempotent.

Using Web Services and SOAP, the request would look something like this:
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:body pb="http://www.develperstack.in/phonebook">
<pb:GetUserDetails>
<pb:UserID>12345</pb:UserID>
</pb:GetUserDetails>
</soap:Body>
</soap:Envelope>
(The details are not important; this is just an example.) The entire shebang now has to be sent (using an HTTP POST request) to the server. The result is probably an XML file, but it will be embedded, as the "payload", inside a SOAP response envelope.
And with REST? The query will probably look like this:
http://www.developerstack.in/phonebook/UserDetails/12345
Note that this isn't the request body -- it's just a URL. This URL is sent to the server using a simpler GET request, and the HTTP reply is the raw result data -- not embedded inside anything, just the data you need in a way you can directly use.

REST is not limited to any particular type of respnses. unlike SOAP services, REST is not bound to XML in any way. Possible formats include CSV (comma-separated values) and JSON (JavaScript Object Notation).

1. 1XX - information.
2. 2XX - Success
3. 3XX - Redirection
4.4XX - Client Error
5. 5XX - Server Error

These are important headers in Restful web services. Accept headers tells web service what kind of response client is accepting, so if a web service is capable of sending response in XML and JSON format and client sends Accept header as “application/xml” then XML response will be sent. For Accept header “application/json”, server will send the JSON response.
Content-Type header is used to tell server what is the format of data being sent in the request. If Content-Type header is “application/xml” then server will try to parse it as XML data. This header is useful in HTTP Post and Put requests.

AJAX is a popular web development technique that makes web pages interactive using JavaScript.
In AJAX, requests are sent to the server using XMLHttpRequest objects. The response is used by the JavaScript code to dynamically change the current page.

1. JAX-RS is an specification (just a definition) and Jersey is a JAX-RS implementation. For example: JAX-RS gives you a set of interfaces (standard Java interfaces) which are implemented by Jersey. So that set of interfaces (or classes) are needed as a dependency to be implemented.
2. In many ways, AJAX applications follow the REST design principles. Each XMLHttpRequest can be viewed as a REST service request, sent using GET. And the response is often in JSON, a popular response format for REST

1. Do not use "physical" URLs.
2. Queries should not return an overload of data. If needed, provide a paging mechanism. For example, a "product list" GET request should return the first n products (e.g., the first 10), with next/prev links.
3. Even though the REST response can be anything, make sure it's well documented, and do not change the output format lightly (since it will break existing clients).
4. Rather than letting clients construct URLs for additional actions, include the actual URLs with REST responses.

WSDL is the Web Services Description Language. It is commonly used to spell out in detail the services offered by a SOAP server. While WSDL is flexible in service binding options (for example, services can be offered via SMTP mail servers), it did not originally support HTTP operations other than GET and POST. Since REST services often use other HTTP verbs, such as PUT and DELETE, WSDL was a poor choice for documenting REST services.
WADL is the Web Application Description Language. WADL is championed by Sun Microsystems. Like the rest of REST, WADL is lightweight, easier to understand and easier to write than WSDL. In some respects, it is not as flexible as WSDL (no binding to SMTP servers), but it is sufficient for any REST service and much less verbose.

no-cache can be set in response in order to inform client/browser that this response should not be used for caching content and any of the cache data should not be sent to server without revalidation from server.
no-store is to inform client/browser as not to store any data in response in local hard disk of the machine that is used for sending the request.
In case of no-cache, one can use data with revalidation, but in no-store that is no ways any data can be retrieved locally from the hard disk and data won't be available when machine if restarted.

HATEOAS stand for Hypermedia As The Engine Of Application State. It provides links to resources so that client does not have to manually bookmark the links. Below is an example.
{
"id":1,
"message":"Hello World",
"author":"Dhiraj",
"href":"/messages/1"
}

There are two basic approaches here.
The first is, use HTTP AUTH. The (human) user will be prompted for the credential just once (or they will be loaded from file, depending on the system at hand). The client software will compute the Base64 encoding of the credentials and will include them in each future HTTP request to the server (using the "Authorization" HTTP header).
The second alternative is to create a dedicated login service, that accepts credentials and returns a token. This token should then be included, as a URL argument, to each following request (e.g., by addding "&authtoken=XYZ" to the URL). Of course, the API (including the argument's name) should be clearly defined.

1. SOAP (Simple Object Access Protocol) is a standard communication protocol on top of transport protocols such as HTTP, SMTP, Messaging, TCP, UDP, etc. whereas REST is an architectural style by which data can be transmitted over transport protocol such as HTTP(S).
2.SOAP only permits XML data formats whereas REST permits many different data formats like XML, JSON data, text, HTML, atom, RSS, etc. JSON is less verbose than XML and is a better fit for data and parses much faster.
3. SOAP Supports both SSL security and WS-security, which adds some enterprise security features. Supports identity through intermediaries, not just point to point SSL whereas REST supports only point-to-point SSL security.

In general, a REST based Web service is preferred due to its simplicity, performance, scalability, and support for multiple data formats. SOAP is favored where service requires comprehensive support for security and transactional reliability.

SoapUI tool for SOAP WS & RESTFul web service testing and on the browser the Firefox “poster” plugin or Google Chrome “Postman” extension for RESTFul services or Advanced Rest Client provided by Google.

JAX-RS is a JSR Specification defining a Java API for RESTful Web Services. Jersey is a specific implementation of JAX-RS.

@GET
@Path("/{empId}")
Employee getEmployee(@PathParam("empId") String empId, @QueryParam("empName") String empName);