We all know how important web services are. Without them facilitating machine to machine communication, there’d be no way for computers to give us wonders like websites and Fortnite. So if you’re planning on getting a new job in the industry, we’ll help you get prepared with web services interview questions. And to make sure you do your best and get the job, we’re also adding REST, RESTful, and SOAP interview questions. Put yourself in the shoes of the interviewee, and let’s get going!
Web Services Interview Questions
1. What are web services?
Web services are communication services which devices can use to communicate with one another (usually over the internet).
Typically, a web service provides an object-oriented interface to a database server. In turn, this server provides a user interface to the end user. The information from one server to another is translated to XML or JSON so they’re universally recognized, and can be applied to different devices.
All of this is done over the network. For example, HTTP is used for machine-to-machine communication in web services.
To put it simply: web services are like phones. One computer “speaks” into one handset, and the other hears it and proceeds with instructions.
2. Can you give me an example of a web service, and why it’s a web service?
A great example of a web service is Apache CXF.
What makes it a web service is that it supports SOAP, addressing, policy, reliable messaging, has a JAX-WS API for development, and uses HTTP, JMS and WebSocket transport layers, among other features.
3. So what are the components of a web service?
A web service should have: SOAP (simple object access protocol), XML (which is a markup language all machines and devices can understand), RDF (resource description framework), UDDI (universal description, discovery and integration), and WSDL (web service description language).
All of this makes it easier for software to communicate, as well as provide seamless support to the end user.
4. What are the main advantages of web services?
Essentially, web services make our jobs a lot easier. They help us use the internet as a tool, instead of a glorified display. And they’re really simple to deploy and integrate.
One of the main advantages of web services is the fact that we can develop them in PHP, while the client is in Java, and they’ll still work. This is because web services run on HTTP/SOAP protocols, and use XML/JSON to communicate.
It’s just as if we spoke Chinese to a French person and they understood us with the help of a translation software. That’s what web services do for tech. The second benefit is reusability. Multiple client apps can use the same web services at the same time. Additionally, multiple versions can run at the same time.
The third benefit of web services is that, with them, we’re achieving loose coupling. The web services client code is separate from the server code, so there’s no dependency.
5. What is a web services protocol stack, and how many layers does it have?
It’s a stack of computer networking protocols we use to make web services interact with each other.
Typically, there are four layers in the web services protocol stack:
The first is the transport layer. It’s responsible for exchanging messages between protocols. Usually, it consists of protocols like HTTP, SMTP, FTP, and the newest one – BEEP (Blocks Extensible Exchange Protocol).
The second layer in the stack is the XML messaging protocol. It encodes messages in XML format so all devices and web apps can understand it. This is where we use protocols such as: XML-RPC, SOAP, and WP-Addressing.
The third layer is the service description protocol. It describes the functions of the public interface to a specific web service. For this, we use the WSDL format.
Finally, the fourth layer is the service discovery protocol, which centralizes services in a common registry. This way, network web services can publish their location and description, and it’s easy to discover what other services are available on the network.
6. What is web service architecture like?
The web service framework consists of three parties we need for web services to do what they’re supposed to.
The first party is the service provider. It creates the web service and makes it available on the internet so client applications can use it.
The second party is the service requestor. This is the application that uses the web service. Again, it can be written in whichever language because it sends the request to the web service in the standardized XML.
The third party is the service registry. It’s a directory of web services client applications can use.
7. How do these three architectural layers interact? What’s the process like?
It’s really simple: the service provider makes the existing web services available (or adds a new one) in the publish interface of the service registry.
Then, the service requestor can invoke services.
8. Where does XML-RPC factor in here, and what are its parts?
Since XML-RPC is a remote procedure call, we can use it to call on functions on remote computers because the call is encoded in XML, and HTTP is its transport mechanism.
It’s just like a message that we send from a computer to another remote computer to say that we want to use its procedures.
The first part of XML-RPC is the data model. It describes types that are used when passing parameters, return values and error messages.
The second part are the request structures, which contain method and parameter information.
Finally, the third part of XML-RPC are the response structures. They contain return values and error information.
9. What is UDDI and how do we use it?
UDDI stands for Universal Description, Discovery, and Integration, and it’s an XML-based registry of web services.
We use it to find other web services client applications can use. It’s an open framework, completely independent of any platforms, and it helps web services discover each other and connect.
It also uses the WSDL language (Web Service Description Language).
10. What do we need to be able to access a web service?
We don’t need anything special. All we need is an application that supports XML requests and responses.
11. What kind of security do we need for web services, what are our main issues, and how can we resolve them?
We need a bit more than your regular SSL since we process a lot of requests and sensitive information. That’s why we can use the ESTP (Entrust Secure Transaction Platform).
The primary three issues of web service security are confidentiality, authentication, and network security.
ESTP deals with confidentiality issues by encrypting messages between clients and servers.
Authentication is performed through application-level authentication, HTTP digest and basic authentication, and client certificates.
Finally, if we want to make sure that the network is secure, we’ll need tools to monitor the traffic.
12. What is stated in WSDL?
Since WSDL in an XML-based document, it contains details about a web service. For example, we can find information on method names, binding, parameters and port types in WSDL.
13. Which two kinds of web services do we have?
SOAP and RESTful.
SOAP Interview Questions
14. What is SOAP and what does it consist of?
It’s an XML-based web service. The acronym stands for Simple Object Access Protocol because it’s a messaging protocol specification.
SOAP consists of three parts: an envelope defining the message structure and specifications on how to process it, encoding rules, and a convention for representing procedure calls and responses.
15. Can you give me an example of what SOAP procedures can do?
Sure! Let’s say we’re looking to rent an apartment.
We enter the parameters, and the application we’re using sends a SOAP request to a real estate database (a server) that uses web services.
This server, the real estate database, returns a SOAP response in the XML format with information on the things we’ve request: price, number of bedrooms, etc.
And since XML is easily understandable to the app we’re using, it can display the search results directly.
16. What are the advantages and disadvantages of using SOAP?
SOAP is very popular, and it has a lot of advantages.
Namely, it’s simple, it has its own security, it’s independent of any languages and platforms because it uses HTTP and XML.
Also, it decouples encoding and communication from the runtime environment.
SOAP’s main disadvantage is that we can’t use JSON – just XML. It’s also relatively slow because the payload uses the XML format.
There’s also coupling between client and server applications with contracts, so if there’s a change in the server-side contract, client classes have to be generated again.
Sometimes, there are also problems with SOAP’s firewall security mechanism.
17. Which conceptual concepts does SOAP have?
SOAP has three conceptual concepts: protocol concepts, encapsulation concepts and network concepts.
18. How can we develop SOAP-based web services?
There are two approaches: contract-first, and contract-last.
If we take the contract-first route, we first define the contract with XML and WSDL, and then we derive the classes.
If we go contract-last, we first define the classes and then derive the contract from them.
However, contract-first is used most often.
19. What does a SOAP message consist of?
A SOAP message consists of four elements which are also known as building blocks:
Envelope, which translates the XML document and defines the start and end of the message.
The header contains specific information about the application, and it adds new functionalities. It’s not mandatory.
The body consists of call and response messages.
Finally, the fault element handles any errors. It’s optional, just like the head.
20. What are the most important characteristics of the envelope, and what are the syntax rules?
It has a root envelope element, which is a mandatory part. We’ll recognize it if we see the “ENV” prefix.
If the envelope includes a header, it can’t contain more than one header element.
Finally, if the SOAP version changes, so will the envelope version.
As for the syntax rules, a SOAP message has to be encoded with XML but not contain XML processing instructions, use the envelope and encoding namespaces, and can’t contain the DTD reference.
21. What functionalities do SOAP protocol classes have?
In order for applications to be able to use a web service, SOAP protocol classes provide functionalities such as: calls for remote methods, deployment descriptors to provide information about SOAP for faster deployment, RPC messages for classes to be able to call and reply to requests, DOM2 writer for translating DOM nodes into XML strings, and service managers for managing all associated SOAP services.
22. How is SOA connected to SOAP?
If we want to create web services like SOAP, we need to use SOA. The acronym stands for service-oriented architecture, and it’s exactly what facilitates the exchange of information between web services and applications.
23. What does SOA consider to be a service?
In order for something to be recognized as a service, the SOA principles state that it should: represent a business activity with defined outcomes, be self-contained, be a black box for its consumers, and may consist of other underlying services.
24. What are the principles of SOA?
There are no defined industry standards, but the majority of industry agrees on a few of them:
First, there should be a standardized service contract with the description of the services.
The second are the principles advocating loose coupling: service reference autonomy strives to minimize the relationship between different services so there’s no dependency, and service location transparency so that services can be called from anywhere within the network regardless of their location.
The services shouldn’t show consumers (client applications) the logic they operate on.
They have to be designed to be long-lived and reusable, as well as stateless.
25. What’s the difference between top-down and bottom-up approach with SOAP?
The top-down approach is another way to describe the contract-first approach, in which the contract is generated first and then the classes are derived.
Similarly, the bottom-up approach corresponds with the contract-last approach where we first write the code and then generate the contract.
26. What is SOAP UI?
It’s an open-source web service that lets us test SOAP, REST Services, and Rest APIs.
Web services can be tested and simulated, and SOAP UI also supports advanced tests such as performance testing and interoperability testing.
27. Is binding between SOAP and WSDL possible?
Yes, by using the Name and Type attributes that define the name and port of the binding. If we want SOAP binding, then we have to use the Transport and Style attributes to specify the SOAP protocol we’ll use.
However, the port can’t contain more than one address or any other binding details except for the address information.
REST Interview Questions
28. What is REST?
The acronym stands for Representational State Transfer. It’s an architectural style that defines the constraints for creating web services. REST for RESTful is like SOA for SOAP.
29. What’s the difference between SOAP and REST?
SOAP is a protocol, while REST is an architectural style. When it comes to coupling, web services and clients are tightly coupled in SOAP, unlike REST.
REST is also lightweight and doesn’t require a lot of resources to run. Additionally, it supports more formats than XML.
Finally, when it comes to security, SOAP defines its own security and uses WSDL for contracts. REST doesn’t have contracts or security method.
30. What are the architectural constraints with REST?
The first REST constraint is the client-server architecture.
This principle separates concerns, such as separating UI concerns from the data storage concerns. This makes it much easier to use the user interface across platforms, as well as scale it. The components of the web service can also evolve independently to support multiple required functionalities.
The second REST constraint is statelessness.
A RESTful web service doesn’t store any information on the client state on its server.
Every time a client wants to make a request, they have to pass its context to the server in order to be serviced. This means that web services don’t have to store info on previous requests, which makes the design simpler and wastes less resources.
The third REST constraint is cacheability.
By storing responses in the web service cache, they don’t have to be generated twice. Instead, with cacheable RESTful web services, they can just be retrieved.
The fourth constraint is creating a layered system.
A client shouldn’t be able to tell if it’s connected to the end server or an intermediary. This improves the scalability through load balancing and shared caches, as well as the security of the service.
The fifth constraint is code on demand.
If the client needs added functionality, the web service should be able to provide them with the ability to create it.
The sixth and final constraint is uniform interface.
In order to simplify and decouple the web service architecture, the uniform interface should have resource identification in requests, the ability to modify resources through representations, descriptive messages with processing instructions, and hypermedia as the engine of application state (HATEOAS).
RESTful Interview Questions
31. What’s the difference between REST and RESTful?
REST is architectural style, and RESTful web services are the web services created with REST.
32. How do we know that a web service is RESTful?
If data and functionality are served as resources, and accessed by uniform resource identifiers (URI), it’s safe to say we’re using or creating a RESTful web service.
33. What is a resource in RESTful web services?
A resource in RESTful is an object with a type, relationships with other resources and methods.
These objects, resources, are identified with HTTP methods they support, request/response data types, formats of data, and their URI.
34. What are the supported HTTP methods in RESTful web services?
The supported methods are: GET, POST, PUT, DELETE, OPTIONS and HEAD.
GET gives us the read-only access to resource. We use PUT if we want to create a new resource, and DELETE if we want to remove an existing one.
If we want to modify or change a resource, we’ll use POST, and OPTIONS show us supported operations for the resource.
Finally, HEAD shows us the HTTP header.
35. How do we use accept and content-type headers in RESTful?
When we’re sending a HTTP request, accept headers show us what type of response the client is accepting (for example, in XML or JSON).
Content-type header tells the web service in which format the data was originally sent. If the header is “application/xml,” the web service will then parse it as XML data.
36. What is JAX-RS API?
It’s the Java API we can use to create RESTful web services.
37. What are the core components of HTTP requests?
The core components of HTTP requests in RESTful web services are: methods (e.g. GET, PUT, etc.), URI, HTTP version information, HTTP request header that contains information about the sent data, and the request body which shows the representation of used resources.
38. What are the core components of HTTP responses?
The core components of HTTP responses are: the request code, HTTP version, HTTP response header, and the response body.
39. How should we design resource representations in RESTful?
First of all, both the clients and servers should be able to understand them. The representation itself has to be complete, no matter if it’s simple or complex.
If the resources are connected to other resources, we have to provide information about them as well.
40. What is payload?
It’s the request data we can find in the body part of HTTP messages. In RESTful, it’s sent through the POST method.
41. What are the best practices for designing RESTful web services?
Inputs on the server should be validated and well-formed, as well as URIs. The message format should comply with the client’s requests.
When it comes to security, URL should never be used to transmit confidential information, and users should be authenticated for every session.