Representational State Transfer (REST) is a style of software architecture for distributed hypermedia systems such as the World Wide Web. The web is built on an architectural style called “REST”. REST provides a definition of a “resource”.

Representations are one of these things that don’t get used a lot. In most cases, a resource has only a single representation.

Look at the coffee table. What are the nouns? Cup, tray, newspaper, remote. Now, what are some things you can do to all of these things? You can get them, pick them up, knock them over, and burn them. You can apply those same exact verbs to any of the objects sitting there.

What if instead of me being able to say to you, “get the cup,” and “get the newspaper,” and “get the remote”; what if instead we needed to come up with different verbs for each of the nouns? Some verbs are more specific than others and apply only to a small set of nouns. For instance, I can’t drive a cup and I can’t drink a car. But some verbs are almost universal like GET, PUT, and DELETE. You can’t DELETE a cup but you can throw it away.

Browsers are pretty much just GET stuff. They don’t do a lot of other types of interaction with resources. It has led many people to assume that HTTP is just for “GETting”. But HTTP is actually a general purpose protocol for applying verbs to nouns.

Think about when you’re browsing around amazon.com looking for things to buy. Imagine each of the products as being nouns. Now, if they were available in a representation that a machine could understand.

At school, three or four computer systems more likely, that let administrators manage students: what classes they’re in, what grades they’re getting, emergency contacts, and information about the books you teach out of, etc. If the systems are web-based, then there’s probably a URL for each of the nouns involved here: student, teacher, class, book, room, etc. Right now, getting the URL through the browser gives you a web page. If there were a machine readable representation for each URL, then it would be trivial to latch new tools onto the system because all of that information would be consumable in a standard way. It would also make it quite a bit easier for each of the systems to talk to each other.

Each of the systems would get information from each other using a simple HTTP GET. If one system needs to add something to another system, it would use an HTTP POST. If a system wants to update something in another system, it uses an HTTP PUT.

The idea is that everything you need to use Web services is already available if you know where to look. HTTP lets you communicate your intentions through GET, POST, PUT, and DELETE requests.

Stateless Web Service Conversation Via REST

REST is a style than a systematic way defining distributed interfaces. Given how it’s used today, there is a big gap between how it’s used and sophisticated software system development.

The key value of OO is higher level of modularity so that developers can think at the object level rather than the function and data level in the procedural programming.

One of the key concepts in REST is resource, which can be created, read, updated, and deleted (CRUD, sounds like SQL?). CRUD is also relevant at the user interface level of most applications. For example, in address book software, the basic storage unit is an individual contact entry. As a bare minimum, the software must allow the user to:

* Create or add new entries

* Read, retrieve, search, or view existing entries

* Update or edit existing entries

* Delete existing entries

Without at least these four operations, the software cannot be considered complete because these operations are so fundamental.

If we think of the different resources as objects, then the gap is filled in some way. Each resource type is defined as a class which has four methods, which correspond to CRUD.

Example:

class Employee

{

Attribute id

Attribute name

Behavior Create()

Behavior Read()

Behavior Update()

Behavior Delete()

}

Now you can easily design a URL that fits REST style:

GET http://<base_url>/obj=<obj_id>&attr=name

This gets you a XML message of attribute name.

POST http://<base_url>/obj=<obj_id>&amp; behavior=create

This activates the method create at the server side with the parameters in POST body which are not shown here.

Issues:

Benefits:

• Focus on the object model design instead of URL syntax
• OO REST is friendly for code generation. Once you have a good object model, you can generate code and facilitate the underlying plumbing code for both the server and client.
• OO REST is still REST even though not in the conventional way. If you like to code at REST level, you can easily guess the URL without looking up the spec for exact URL pattern as you have to do today.
  Other interesting Java related Posts you may like :
  What is Java?(clean-clouds.com)Object-Oriented Programming Concepts (clean-clouds.com)

  Java Language Fundamentals (clean-clouds.com)

  Operators, Expressions and Control Structures in Java (clean-clouds.com)

  Creating, Compiling and Running a Simple program in Java (clean-clouds.com)

  Generics and Collections in Java (clean-clouds.com)

  Applet and Swing in Java (clean-clouds.com)

  JDBC in Java (clean-clouds.com)

  Basic I/O in Java (clean-clouds.com)

  Threads in Java (clean-clouds.com)

  Packages in Java (clean-clouds.com)

  Exceptions in Java (clean-clouds.com)

  Using JavaDoc to document your Java Program (clean-clouds.com)

  Java Coding Standards (clean-clouds.com)

  Open Source ILS: Installation Guide for Koha on Ubuntu 11.10 or Ubuntu 11.04 or Ubuntu 10.10 or Ubuntu 10.04 LTS with MySQL 5 (clean-clouds.com)

  REST and OO REST (clean-clouds.com)

  Java Application in One JAR (clean-clouds.com)

  Obfuscation in Java (clean-clouds.com)

  Encryption~Hybrid Approach (clean-clouds.com)

References:

How I Explained REST to My Wife

Object Oriented REST