REST and RESTful systems

REST stands for Representational State Transfer and basically refers to systems where sufficient information is transferred from one place to another for the state of the target system to be defined solely by the information transferred. A simple URL is an example of a RESTful system.

RESTfulness refers to resources - so a 'forbidden' message (say, due to a cookie being deleted) indicates a lack of success at accessing a resource, rather than indicating a different system state. Similarly, the access level of a user based on information set in a cookie might receive a different rendering of the same 'thing' (resource), but is still basically the same thing.

Resources are considered 'nouns'; the operation is a considered a verb. So using the HTTP GET method on a resource can be understood as 'Getting some information about this noun (thing)'. Similarly PUTting and POSTing are understood to have certain meanings and behaviour. It appears fairly clear from the URL what the desired resource is, as well as the nature of the operation (as defined by the HTTP method, GET, POST, PUT, etc).

One of the purposes of REST is to ensure that pages can be cached. The formal REST spec provides for caching servers to ensure that appropriate cached copies are returned (the header including cookies are examined). Idempotency is an important feature of RESTful systems - defined as something along the lines of if a function is applied to something, applying the same function again and again should not change the result. A nice example is the absolute value function in mathematics.

RESTful systems are often exemplified by referring to resources in a URL, so:

• www.domain.org/database might refer to a database
• www.domain.org/database/tables/1 might refer to table1 on database
• www.domain.org/database/tables/1/rows/5 might refer to the 5th row of the database table 1

And:

• If a GET request is directed to www.domain.org/database/tables/1, the system might return the contents of table1 in database.
• If a GET request is directed to www.domain.org/database/tables/1/rows/5, the system might return the contents of row5 of table1 in database.
• If a POST submission is made to www.domain.org/database/tables/1/rows, it will add a record containing information in the POST submission
• If a PUT submission is made to www.domain.org/database/tables/1/rows/5, the 5th row of the database table is updated.

Ultimately, this is a subjective issue of where to draw the line and what to consider a resource and various other things. Dan reckons it is increasingly a return to the original concepts of the web.

From: http://en.wikipedia.org/wiki/REST; http://www.xfront.com/, Billingsley W (pers. comm.) and Basman A (pers. comm.)

XSD: XML Schema Definition

The last time I was seriously involved with XML, DTD seemed to be the accepted way of definining an XML schema. That seems to have been abandoned in favour of a XML-based schema-definition, er, schema, called XSD.

An example of a very simple XML Schema Definition to describe a UK Address

<?xml version="1.0" encoding="utf-8" ?>
<xs:schema elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Address">
 <xs:complexType>
   <xs:sequence>
     <xs:element name="Recipient" type="xs:string" />
     <xs:element name="House" type="xs:string" />
     <xs:element name="Street" type="xs:string" />
     <xs:element name="Town" type="xs:string" />
     <xs:element minOccurs="0" name="County" type="xs:string" />
     <xs:element name="PostCode" type="xs:string" />
     <xs:element name="Country">
       <xs:simpleType>
         <xs:restriction base="xs:string">
           <xs:enumeration value="FR" />
           <xs:enumeration value="DE" />
           <xs:enumeration value="ES" />
           <xs:enumeration value="UK" />
           <xs:enumeration value="US" />
         </xs:restriction>
       </xs:simpleType>
     </xs:element>
   </xs:sequence>
 </xs:complexType>
</xs:element>
</xs:schema>

An example:

<?xml version="1.0" encoding="utf-8"?>
<Address xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="SimpleAddress.xsd">
 <Recipient>Mr. Walter C. Brown</Recipient>
 <House>49</House>
 <Street>Featherstone Street</Street>
 <Town>LONDON</Town>
 <PostCode>EC1Y 8SY</PostCode>
 <Country>UK</Country>
</Address>

 

From: http://en.wikipedia.org/wiki/XML_Schema_(W3C)

JSON - JavaScript Object Notation

JSON is a really cunning text-based data transfer object transfer format. Various basic data types (Strings, ints, etc) can be stored in object relationships. It is intended (used?) as a 'lightweight' alternative to XML, which tends to be heavy and wordy.

Example:

JSON format:

{
  "firstName": "John",
  "lastName": "Smith",
  "address": {
      "streetAddress": "21 2nd Street",
      "city": "New York",
      "state": "NY",
      "postalCode": 10021
  },
  "phoneNumbers": [
      "212 555-1234",
      "646 555-4567"
  ]
} 

In JavaScript, an object can be created of this as follows:

var p = eval('(' + contact + ')');

In JavaScript, the object attributes can be accessed as follows:

p.firstName, p.address.city, p.phoneNumbers[0]


It appears that use of schemas is possible but somehow outside the core JSON vibe. Care must be taken to ensure that dangerous js code is not inserted into the JSON string, which would be executed with the eval() statement.

In PHP:

$popups = array();

$popups[] = 'This is the first popup';
$popups[] = 'This is the second popup';

$return['popups'] = $popups;
$return['result'] = 'success';

// output correct header
$isXmlHttpRequest = (isset($_SERVER['HTTP_X_REQUESTED_WITH'])) ?
 (strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest') ? true : false: false;
($isXmlHttpRequest) ? header('Content-type: application/json') : header('Content-type: text/plain');

echo json_encode($return);
?> 

This info summarised from the kindly Wikipedia: http://en.wikipedia.org/wiki/JSONP#JSONP