Describe briefly the architectural principles of RESTful Web Services ?
The architectural principle of RESTful web services are as follows:

Addressability
Addressability is an important principle to follow when designing RESTful web services that make an application as addressable as possible, which means that every valuable piece of information in an application should be a resource and have a URI, making that resource easily accessible.

The URI is the only piece of data that need to publish to make the resource accessible, the Each HTTP request must contain the URI of the object that are requesting information from or posting information to.

Using a unique URI to identify each of the services makes each of the resources linkable.

The Uniform, Constrained Interface

The use of a uniform interface is to manage the resources.Use it from resource to resource, and from service to service. Never lost from it or alter the original meaning.

The actual web protocol is HTTP, which is a document-based standardized request/response protocol between a client and a server. HTTP is the uniform interface of RESTful web services. So web services built on SOAP, WSDL, and other WS-* standards also use HTTP as the transport layer.

The RESTful web services have a uniform interface (HTTP methods and URIs), so, where the resource is (URI), invoke the HTTP method (GET, POST, etc.).

HTTP Methods
The Web consists of well-identified resources linked together and accessed through simple HTTP requests. HTTP has a small, fixed set of operational methods. Each method has a specific purpose and meaning. HTTP methods are:

GET
GET is a read-only operation. It is used to query the server for specific information. It is an idempotent as well as safe operation. Idempotent means that the result is always same no matter how
many times apply for the operation and Safe means that invoking a
GET does not change the state of the server at all. Safety and idempotence bring greater stability.

POST
POST is the only nonidempotent and unsafe operation . Every POST method is allowed to modify the service in a particular way.

PUT
Under the location provided in the HTTP message the server store the message body sent with the request that PUT requests . It is mainly formed as an insert or update. It is also idempotent. So because of this sending the same PUT message more than once has no effect on the basic service.

DELETE
DELETE is used to remove the resources. It is idempotent also.

Others HTTP methods
HEAD
HEAD is exactly like GET except that instead of returning a response body, HEAD method returns only response code and either headers associated with the request.

 TRACE

When a server receives a TRACE request from the client, it echoes back the received request. This can be useful to see what intermediate servers, proxies or firewalls are adding or changing
in the request.

OPTIONS
This method is used to request information about the communication. It allows the client to determine the capabilities of a
server and a resource.

CONNECT

Used in conjunction with a proxy that can dynamically switch to being a tunnel.

The HTTP methods like TRACE and CONNECT, are unimportant
during designing and implementing RESTful web services.

In a RESTful system, the complexity of the client-server interaction is within the representations being passed back and forth. These representations can be XML, JSON, YAML.

Representation-Oriented
The third principle of REST is that services should be representation oriented. Each and every service is addressable through a particular URI and representations are exchanged between the client and service. With a GET method receiving a representation of the current state of the resource. A PUT or POST method passes a representation of the resource to the server so that the basic resource’s state can change.

With HTTP, the representation is the message body of request or response.When the client deals with a resource, it is always through its representation, the resource itself remains on the server. Representation is any useful information about the state of a resource.

Communicate Statelessly
Statelessness, which means that every HTTP request happens in complete isolation, as the server should never keep track of requests that were executed before. For the sake of clarity, resource state and application state are usually distinguished. The resource state must live on the server and is shared by everybody, while the application state must remain on the client and is its sole property.
Statelessness comes with many advantages such as better scalability: no session information to handle, no need to route subsequent requests to the same server i.e. load-balancing, failure handling e.g. service interruptions, and so on.

HATEOAS
The last principle of REST is the concept of using Hypermedia As The Engine Of Application State (HATEOAS). Hypermedia is a document-centric approach with the added support for insert links to other services and information within that document format. One of the uses of hypermedia and hyperlinks is composing complex sets of information from disparate sources HATEOAS is a bit be
different because with each and every request returned from a server it tells what new interactions can do next, as well as where to go to transition the state of an applications.