is your Web API really Restful ?

REST, or Representational State Transfer, is probably one of the most misunderstood terms in Web API development today. Most people equate REST with anything that is easy to access over HTTP and forget about its constraints completely.

The RESTful constraints are designed to create a system that achieves a certain set of goals—in particular, a system that can evolve over a long period of time and can tolerate many different clients and many different changes without breaking those clients.

if your API doesnot meet these constraint , then , it is not Restful.

REST Constraints

Client-server
A RESTful system is designed to separate out the UI concerns from the backend.
Clients are decoupled from the server, thus allowing both to evolve independently.

Stateless
For each request in a RESTful system, all of the application state is kept on the client and transferred in the request. This allows the server to receive all the information it needs to process the request without having to track each individual client. Removing statefulness from the server allows the application to easily scale.

Cache
Data within a request must be able to be identified as cachable. This allows client and server caches to act on behalf of the origin server and to return cached representations. Cachability greatly reduces latency, increases user-perceived performance,and improves overall system scale, as it decreases the load on the server.

Uniform interface
RESTful systems use a standardized interface for system interaction.
Identification of resources
This means that the point of interaction in a RESTful system is a resource. This is the same resource that we discussed earlier.

Self-descriptive messages
This means that each message contains all the information necessary for clients and servers to interact. This includes the URI, HTTP method, headers, media type, and more.

Manipulation of resources through representations
As we covered previously, a resource can have one or more representations. In a
RESTful system, it is through these representations that resource state is communicated.

Hypermedia as the engine of application state
Previously we discussed hypermedia and the role it plays in driving the flow of the application. That model is a core component of a RESTful system.

Layered system
Components within a RESTful system are layered and composed with each component having a limited view of the system. This allows layers to be introduced to adapt between legacy clients and servers and enables intermediaries to provide additional services like caching, enforcing security policies, compression, and more.

Code on demand
This allows clients to dynamically download code that executes on the client in
order to help it interact with the system. One very popular example of this is the
way client-side JavaScript executes in the browser, as it is downloaded on demand. Being able to introduce new application code improves the the system’s capacity to evolve and be extended. Because it reduces visibility, however, this constraint is considered optional.

As you can see, building a RESTful system is not free and not necessarily easy so think again before you use (REST) in your Web API