Webservices:

I. What are web services?

Web services are client and server applications that communicate over the World Wide Web’s (WWW)
HyperText Transfer Protocol (HTTP). Web service is a way of communication that allows interoperability
between different applications on different platforms, for example, a java based application on Windows can
communicate with a .Net based one on Linux. The communication can be done through a set of XML
messages over HTTP protocol.

Web services are browsers and operating system independent service, which means it can run on any
browser without the need of making any changes. Web Services take Web-applications to the Next Level.

The Web of Services is based on technologies such as HTTP, XML, SOAP, WSDL, SPARQL, and others.”Web
services can be combined in a loosely coupled way to achieve complex operations. Programs providing
simple services can interact with each other to deliver sophisticated added-value services.

II. How to secure web services from unauthorized access?

Although web services are generally a good idea, they lack some practical features. For example, systemized
security and authentication support.
If developers would like to have their web services authenticated, they must write and implement it
themselves. Also confidentiality of communication is not guaranteed, if SSL is not in use.

WS-Security standard solves three basic problems:

Authentication and authorization of users – along with web service call, you can now pass authentication
information, login and password. These values are automatically processed at server side.
Message integrity – messages can be digitally signed, which eliminates the possibility to modify them on the
way.
Message encryption – SOAP messages can be encrypted, even when sent via non-encrypted channel such as
HTTP, to ensure privacy.

To use authentication, you must create a class, implementing the

Microsoft.Web.Services.Security.IPasswordProvider interface. It must contain method GetPassword, which
would return plaintext password for specified user.

A second thing you need to do is to setup Web.Config. It must tell your application that it should use your
class to check passwords.

At this moment, all web service requests containing authentication information would be checked for their
validity and in case of error refused automatically.
 WSE will let go through, request without any authentication information. At this time, you would probably
want also to check, if the web service is called via the SOAP protocol, not by simply using HTTP GET or POST,
which cannot implement WS-Security.

III. Write a program for creating Restful web service?

http://www.javacodegeeks.com/2013/11/restful-web-services-with-java.html

IV. What is the difference between Rest and SOAP based web services?

V. Give scenarios where Restful web services should be implemented and where SOAP based web services?
REST works really well for are:
1. Limited bandwidth and resources; remember the return structure is really in any format (developer
defined). Plus, any browser can be used because the REST approach uses the standard GET, PUT,
POST, and DELETE verbs. Again, remember that REST can also use the XMLHttpRequest object that
most modern browsers support today, which adds an extra bonus of AJAX.
2. Totally stateless operations; if an operation needs to be continued, then REST is not the best
approach and SOAP may fit it better. However, if you need stateless CRUD (Create, Read, Update,
and Delete) operations, then REST is it.
3. Caching situations; if the information can be cached because of the totally stateless operation of the
REST approach, this is perfect.
 SOAP is a great solution:
1. Asynchronous processing and invocation; if your application needs a guaranteed level of reliability
and security then SOAP 1.2 offers additional standards to ensure this type of operation. Things like
WSRM – WS-Reliable Messaging.
2. Formal contracts; if both sides (provider and consumer) have to agree on the exchange format then
SOAP 1.2 gives the rigid specifications for this type of interaction.
3. Stateful operations; if the application needs contextual information and conversational state
management then SOAP 1.2 has the additional specification in the WS* structure to support those
things (Security, Transactions, Coordination, etc). Comparatively, the REST approach would make
the developers build this custom plumbing.
Additional information:
1. SOAP stands for Simple Object Access Protocol. REST stands for REpresentational State Transfer.
2. SOAP is a XML based messaging protocol and REST is not a protocol but an architectural style.
3. SOAP has a standard specification but there is none for REST.
4. Whole of the web works based on REST style architecture. Consider a shared resource repository
and consumers access the resources.
5. Even SOAP based web services can be implemented in RESTful style. REST is a concept that does not
tie with any protocols.
6. SOAP is distributed computing style and REST is web style (web is also a distributed computing
model).
7. REST messages should be self-contained and should help consumer in controlling the interaction
between provider and consumer(example, links in message to decide the next course of action). But
SOAP doesn’t has any such requirements.
8. REST does not enforces message format as XML or JSON or etc. But SOAP is XML based message
protocol.
9. REST follows stateless model. SOAP has specifications for stateful implementation as well.
10. SOAP is strongly typed, has strict specification for every part of implementation. But REST gives the
concept and less restrictive about the implementation.
11. Therefore REST based implementation is simple compared to SOAP and consumer understanding.
12. SOAP uses interfaces and named operations to expose business logic. REST uses (generally) URI and
methods like (GET, PUT, POST, DELETE) to expose resources.
13. SOAP has a set of standard specifications. WS-Security is the specification for security in the
implementation. It is a detailed standard providing rules for security in application implementation.
Like this we have separate specifications for messaging, transactions, etc. Unlike SOAP, REST does
not has dedicated concepts for each of these. REST predominantly relies on HTTPS.
14. Above all both SOAP and REST depends on design and implementation of the application.

VI. What is the protocol over which Restful web services work?
REST stands for Representational State Transfer. (It is sometimes spelled "ReST".) It relies on a stateless,
client-server, cacheable communications protocol -- and in virtually all cases, the HTTP protocol is used.
VII. What is the underlying protocol for http?
TCP

VIII. On which protocol, browser works?

The browser uses HTTP, an application protocol layered over TCP, which is a connection-oriented protocol.
Or else it uses HTTPS, which is HTTP over SSL over TCP.