RESTFul Web Service Interview Questions

What is a REST and RESTful web service?

REST stands for REpresentational State Transfer (REST), it’s a relatively new concept of writing web services which enforces a stateless client server design where web services are treated as resource and can be accessed and identified by their URL unlike SOAP web services which were defined by WSDL.

Web services written by apply REST Architectural concept are called RESTful web services which focus on System resources and how state of Resource should be transferred over http protocol to a different clients written in different languages. In RESTful web services http methods like GET, PUT, POST and DELETE can be used to perform CRUD operations.

What is difference between top-down and bottom-up approach of developing web services?

In top-down approach first WSDL document is created and then Java classes are developed based on WSDL contract, so if WSDL contract changes you got to change your Java classes while in case of bottom up approach of web service development you first create Java code and then use annotations like @WebService to specify contract or interface and WSDL field will be automatically generated from your build.

What happens if RestFull resources are accessed by multiple clients? Do you need to make it thread-safe?

Since a new Resource instance is created for every incoming Request there is no need to make it thread-safe or add synchronization. Multiple clients can safely access RESTful resources concurrently.

Can I use GET request instead of PUT to create resources?

No, you are supposed to use PUT or POST. GET operations should only have view rights.

What is meant by JAX-WS and JAX-RS?

Java API for XML Web Services(JAX-WS)

Java API for RESTful Web Services (JAX-RS)

What are the different application integration styles?

There is a number of different integration styles like

1. Shared database

2. Batch file transfer

3. Invoking remote procedures (RPC)

4. Exchanging asynchronous messages over a message oriented middle-ware (MOM).

How would you decide what style of Web Service to use? SOAP WS or REST?

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.

The answer really depends on the functional and non-functional requirements. Asking the questions listed below will help you choose.

Does the service expose data or business logic? (REST is a better choice for exposing data, SOAP WS might be a better choice for logic).Do the consumers and the service providers require a formal contract? (SOAP has a formal contract via WSDL)

Do we need to support multiple data formats?

Do we need to make AJAX calls? (REST can use the XMLHttpRequest)

Is the call synchronous or asynchronous?

Is the call stateful or stateless? (REST is suited for stateless CRUD operations)

What level of security is required? (SOAP WS has better support for security)

What level of transaction support is required? (SOAP WS has better support for transaction management)

Do we have limited band width? (SOAP is more verbose)

What’s best for the developers who will build clients for the service? (REST is easier to implement, test, and maintain)

What tools do you use to test your Web Services?

SoapUI tool for SOAP WS and the Firefox “poster” plugin for RESTFul services.

What is a difference between RESTful web services and SOAP web services?

Though both RESTful web series and SOAP web service can operate cross platform they are architecturally different to each other, here is some of differences between REST and SOAP:

1) REST is more simple and easy to use than SOAP. REST language is based on use of nouns and verbs (better readability)

2) REST uses HTTP protocol for producing or consuming web services while SOAP uses XML.

The SOAP WS is transport protocol neutral. Supports multiple protocols like HTTP(S), Messaging, TCP, UDP SMTP, etc.

The REST is transport protocol specific. Supports only HTTP or HTTPS protocols.

3) REST is lightweight as compared to SOAP and preferred choice in mobile devices and PDA’s. REST does not need XML parsing, no message header (to and from), hence less bandwidth

4) REST supports different format like text, JSON and XML while SOAP only support XML.

The SOAP WS permits only XML data format. You define operations, which tunnels through the POST. The focus is on accessing the named operations and exposing the application logic as a service.

The REST permits multiple data formats like XML, JSON data, text, HTML, etc. Any browser can be used because the REST approach uses the standard GET, PUT, POST, and DELETE Web operations. The focus is on accessing the named resources and exposing the data as a service. REST has AJAX support. It can use the XMLHttpRequest object. Good for stateless CRUD (Create, Read, Update, and Delete) operations.

GET – represent()

POST – acceptRepresention()

PUT – storeRepresention()

DELETE – removeRepresention()

5) SOAP based reads cannot be cached. REST based reads can be cached. Performs and scales better.

6) Different error handling:

REST: requires HTTP error handling

SOAP: can have user defined error

7) REST only supports synchronous message because of its reliance of HTTP and HTTPS

8) SOAP WS supports both SSL security and WS-security, which adds some enterprise security features like maintaining security right up to the point where it is needed, maintaining identities through intermediaries and not just point to point SSL only, securing different parts of the message with different security algorithms, etc.

The REST supports only point-to-point SSL security. The SSL encrypts the whole message, whether all of it is sensitive or not.

9) The SOAP has comprehensive support for both ACID based  transaction management  for short-lived transactions and compensation based transaction management for long-running transactions. It also supports two-phase commit across distributed resources.

The REST supports transactions, but it  is neither ACID compliant nor can provide two phase commit across distributed transactional resources as it is limited by its HTTP protocol.

10) The SOAP has success or retry logic built in and provides end-to-end reliability even through SOAP intermediaries. REST does not have a standard messaging system, and expects clients invoking the service to deal with communication failures by retrying.