29 Web Services Interview Questions To Prepare For

REST is the acronym for REpresentational State Transfer. REST is an architectural style for developing applications that can be accessed over the network. REST architectural style was brought in light by Roy Fielding in his doctoral thesis in 2000.

REST is a stateless client-server architecture where web services are resources and can be identified by their URIs. Client applications can use HTTP GET/POST methods to invoke Restful web services. REST doesn’t specify any specific protocol to use, but in almost all cases it’s used over HTTP/HTTPS.

When compared to SOAP web services, these are lightweight and doesn’t follow any standard. We can use XML, JSON, text or any other type of data for request and response.

There are two types of web services:

• SOAP Web Services: Runs on SOAP protocol and uses XML technology for sending data.
• Restful Web Services: It’s an architectural style and runs on HTTP/HTTPS protocol almost all the time. REST is a stateless client-server architecture where web services are resources and can be identified by their URIs. Client applications can use HTTP GET/POST methods to invoke Restful web services.

Resource is the fundamental concept of Restful architecture. A resource is an object with:

• a type,
• relationship with other resources and
• methods that operate on it.

Resources are identified with:

• their URI,
• HTTP methods they support and
• request/response data type and format of data.

URI stands for Uniform Resource Identifier. Each resource in REST architecture is identified by its URI. Purpose of an URI is to locate a resource(s) on the server hosting the web service.

A URI is of following format:

<protocol>://<service-name>/<ResourceType>/<ResourceID>

A Root SSL certificate is a certificate issued by a trusted certificate authority (CA).

In the SSL ecosystem, anyone can generate a signing key and sign a new certificate with that signature. However, that certificate is not considered valid unless it has been directly or indirectly signed by a trusted CA.

A trusted certificate authority is an entity that has been entitled to verify that someone is effectively who it declares to be. In order for this model to work, all the participants on the game must agree on a set of CA which they trust. All operating systems and most of web browsers ship with a set of trusted CAs.

• Clients – Different users from various devices send requests.
• Identity Providers – Authenticates user or clients identities and issues security tokens.
• API Gateway – Handles client requests.
• Static Content – Houses all the content of the system.
• Management –  Balances services on nodes and identifies failures.
• Service Discovery – A guide to find the route of communication between microservices.
• Content Delivery Networks – Distributed network of proxy servers and their data centers.
• Remote Service – Enables the remote access information that resides on a network of IT devices.

Web Services work on client-server model and when it comes to choose between SOAP and REST, it all depends on project requirements. Let’s look at some of the conditions affecting our choice:

• Do you know your web service clients beforehand? If Yes, then you can define a contract before implementation and SOAP seems better choice. But if you don’t then REST seems better choice because you can provide sample request/response and test cases easily for client applications to use later on.
• How much time you have? For quick implementation REST is the best choice. You can create web service easily, test it through browser/curl and get ready for your clients. What kind of data format are supported? If only XML then you can go with SOAP but if you think about supporting JSON also in future then go with REST.

In document style web services, we can transport an XML message as part of SOAP request which is not possible in RPC style web service. Document style web service is most appropriate in some application where XML message behaves as document and content of that document can alter and intention of web service does not rely on the content of XML message.

• SOAP web services can be tested programmatically by generating client stubs from WSDL or through software such as Soap UI.

• REST web services can be tested easily with program, curl commands and through browser extensions. Resources supporting GET method can be tested with browser itself, without any program.

Some of the disadvantages of REST are:

• Since there is no contract defined between service and client, it has to be communicated through other means such as documentation or emails.
• Since it works on HTTP, there can’t be asynchronous calls.
• Sessions can’t be maintained.

Microservices

• Service Startup is fast
• Microservices are loosely coupled architecture.
• Changes done in a single data model does not affect other Microservices.
• Microservices focuses on products, not projects

Monolithic Architecture

• Service startup takes time
• Monolithic architecture is mostly tightly coupled.
• Any changes in the data model affect the entire database
• Monolithic put emphasize over the whole project

Following is the disadvantage of statelessness in RESTful web services:

• Web services need to get extra information in each request and then interpret to get the client's state in case client interactions are to be taken care of.

To ensure reliable transactions and secure confidential information, web services requires very high level of security which can be only achieved through Entrust Secure Transaction Platform. Security issues for web services are broadly divided into three sections as described below

1) Confidentiality: A single web service can have multiple applications and their service path contains a potential weak link at its nodes. Whenever messages or say XML requests are sent by the client along with the service path to the server, they must be encrypted. Thus, maintaining the confidentiality of the communication is a must.

2) Authentication: Authentication is basically performed to verify the identity of the users as well as ensuring that the user using the web service has the right to use or not? Authentication is also done to track user’s activity. There are several options that can be considered for this purpose

• Application level authentication
• HTTP digest and HTTP basic authentication
• Client certificates

3) Network Security: This is a serious issue which requires tools to filter web service traffic.

Addressing refers to locating a resource or multiple resources lying on the server. It is analogous to locate a postal address of a person.

A client sends a message in form of a HTTP Request and server responds in form of a HTTP Response. This technique is termed as Messaging. These messages contain message data and metadata i.e. information about message itself.

As per REST architecture, a RESTful web service should not keep a client state on server. This restriction is called statelessness. It is responsibility of the client to pass its context to server and then server can store this context to process client's further request. For example, session maintained by server is identified by session identifier passed by the client.

Encryption, encoding and hashing are techniques used for converting the format of data.

• Encryption is used for changing plain text into cipher text so that only authorized entities can understand it. Encryption deals with keys which are used to encrypt and decrypt the data. These keys are used to transform a simple text into a cypher text and the vice versa.
• Encoding is used for changing the data into a special format which makes it usable by external processes. Unlike encryption, the intention of encoding is not related to security. The message is encoded by using an algorithm or scheme.
• In hashing, the data is converted to a message digest or hash, which is usually a number generated from a string of text. Hashing is not reversible as encryption and encoding. The data is converted to a message digest or hash, which is usually a number generated from a string of text. These digests are important as one can easily match the hash of sent and received messages to ensure that both are the same and no tempering is done with the data.

GraphQL and microservices are a perfect fit, because GraphQL hides the fact that you have a microservice architecture from the clients. From a backend perspective, you want to split everything into microservices, but from a frontend perspective, you would like all your data to come from a single API. Using GraphQL is the best way I know of that lets you do both. It lets you split up your backend into microservices, while still providing a single API to all your application, and allowing joins across data from different services.