Skip to main content

Building Web Services the REST Way

Popularity Report

Total Popularity Score: 0
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...

Rank

Bookmark History

Saved by 66 people (17 private), first by anonymouse user on 2006-07-02


Public Comment

on 2006-07-31 by ziller

I will first provide a brief introduction to REST and then describe how to build Web services in the REST style.

on 2006-10-17 by webjoy

I'm considering a REST style search protocol.

on 2006-10-30 by delgaudm

Good voerview guidelines for creating a RESTful API

Public Sticky notes

REST Web Services Characteristics

Here are the characteristics of REST:
  • Client-Server: a pull-based interaction style: consuming components pull representations.
  • Stateless: each request from client to server must contain all the information necessary to understand the request, and cannot take advantage of any stored context on the server.
  • Cache: to improve network efficiency responses must be capable of being labeled as cacheable or non-cacheable.
  • Uniform interface: all resources are accessed with a generic interface (e.g., HTTP GET, POST, PUT, DELETE).
  • Named resources - the system is comprised of resources which are named using a URL.
  • Interconnected resource representations - the representations of the resources are interconnected using URLs, thereby enabling a client to progress from one state to another.
  • Layered components - intermediaries, such as proxy servers, cache servers, gateways, etc, can be inserted between clients and resources to support performance, security, etc.

Highlighted by kayflow

The Web is comprised of resources. A resource is any item of interest.

Highlighted by kayflow

Motivation for REST

The motivation for REST was to capture the characteristics of the Web which made the Web successful. Subsequently these characteristics are being used to guide the evolution of the Web.

Highlighted by kayflow

REST - An Architectural Style, Not a Standard

Highlighted by kayflow

free to modify the underlying implementation of this resource without impacting clients. This is loose coupling.

Highlighted by kayflow

<?xml version="1.0"?> <p:Parts xmlns:p="http://www.parts-depot.com" xmlns:xlink="http://www.w3.org/1999/xlink"> <Part id="00345" xlink:href="http://www.parts-depot.com/parts/00345"/> <Part id="00346" xlink:href="http://www.parts-depot.com/parts/00346"/> <Part id="00347" xlink:href="http://www.parts-depot.com/parts/00347"/> <Part id="00348" xlink:href="http://www.parts-depot.com/parts/00348"/> </p:Parts>

Highlighted by kayflow

Principles of REST Web Service Design

Highlighted by kayflow

What is REST? >

REST is a term coined by Roy Fielding in his Ph.D. dissertation [1] to > describe an > architecture style > of networked systems. REST is > an acronym standing for Representational State Transfer. >

Highlighted by pwagneratss

What is REST? > >

R EST is a term coined by Roy Fielding in his Ph.D. dissertation [1] t >o > d escribe a >n > a rchitecture styl >e > o f networked systems. REST i >s > a n acronym standing for Representational State Transfer >. >

Highlighted by pwagneratss

REST

Highlighted by ericwangqing

Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use.

Highlighted by navneetk

REST is just an architectural style.

Highlighted by navneetk

REST is concerned with the "big picture" of the Web. It does not deal with implementation details

Highlighted by navneetk

Logical URLs versus Physical URLs

Highlighted by navneetk

the system is comprised of resources which are named using a URL.

Highlighted by navneetk

The resources should be nouns, not verbs.

Highlighted by navneetk

Categorize your resources according to whether clients can just receive a representation of the resource, or whether clients can modify (add to) the resource. For the former, make those resources accessible using an HTTP GET. For the later, make those resources accessible using HTTP POST, PUT, and/or DELETE.

Highlighted by navneetk