CODEWITHSUNDEEP
javaweb-servicesrestrestful-architecture
Anuj Balan
Anuj Balan

Reputation: 7729

What does RESTful web service actually does that HTTP programming doesn't? What is the main use of RESTful WS

I know RESTful WS is an architecture all together, which is a new way of implementing Web Services over old fashioned JAX-RPC's.

In RESTful, we use @GET, @POST, etc to manage calls/develop resources. Same can be achieved using HTTP programming (both are stateless too). But what are other core main uses or need for bringing/implementing RESTful? As everything we do in it, can be done using HTTP programming (in which we use same methods)?

Upvotes: 0

Views: 106

Answers (3)

Davide Lorenzo MARINO
Davide Lorenzo MARINO

Reputation: 26926

HTTP is a transfer protocol.

RESTful is a group of principles.

Basically a RESTful web service is a particular HTTP application that follow the following principles:

  • client server
  • stateless
  • cacheable
  • layered

Upvotes: 1

Pedro Werneck
Pedro Werneck

Reputation: 41878

The question is comparing different things. HTTP is a protocol, while REST is an architectural style. This is like asking what a house does that a brick doesn't. It doesn't make sense. HTTP can be a building block of a REST application.

REST is not about HTTP or any particular protocol. REST is about applying the successful design decisions of the Web itself to software development. The problem is terminology. 99.9% of the so called REST applications around the internet aren't really RESTful, because REST became a buzzword to refer to any HTTP API that isn't SOAP. Some REST advocates gave up on fighting for the proper usage of the term and now refer to REST applications as Hypermedia.

Like the Web, REST is intended for software development in the scale of decades. REST makes it easier to evolve your application without breaking clients. Think about how today you can still access websites that were created decades ago, and almost everything still works fine. If you're creating software that has long-term objectives in the scale of several years, then maybe REST is adequate for you. If that's not what you really need, then getting REST right is not important. Just use whatever works for you, and at this point I think nobody cares anymore if you call it REST.

Upvotes: 2

JanTheGun
JanTheGun

Reputation: 2213

The question is not "REST versus HTTP-Programing". REST is a higher concept on how to to create distributed web applications. HTTP is a concrete technology . REST defines some constraints which are considered as good practice.

HTTP is just a technology which is well suited to implement REST-Style services:

  • Addressability => in HTTP every resource can be addressed through a unique identifier (URI)
  • multiple Representations => every resource can have multiple representations (JSON, XML) - a HTTP-Request for instance can 'ask' for the right representation (via headers)
  • Common Interface => Instead of creating an application specific interface (Methodnames in SOAP) HTTP already provides an Interface: GET, PUT, POST, DELETE ...)
  • Stateless => HTTP-Requests are stateless by design
  • Hypermedia => The application state (client) is driven by examining the links contained in the representations

Upvotes: 1

Related Questions