REST - Representational State Transfer

REST c'est mieux

REST vs RPC

Une application RPC est exposée comme un objet du réseau et particulièrement comme un ensemble défini de méthodes pouvant être appelées. Pour communiquer avec l'application, un client devra avoir connaissance de l'identité de l'objet en vue de le localiser et doit également avoir une connaissance de type d'objet afin de communiquer avec.

Une application RPC pourrait définir des méthodes de la manière suivante :

	getBook()
	addBook()
	removeBook()
	updateBook()
	getAuthor()
	addAuthor()
	removeAuthor()
	updateAuthor()
	listBooks()
	listAuthors()
	findAuthor()
	findBook()
			

Pour accéder à l'application le client fera donc :

	libraryObject = new LibraryApp('library.com:5432')
	libraryObject.removeBook('001')			
			

Avec REST l'accent est mis sur la diversité des ressources, par exemple, une application peut REST définir les ressources suivantes :

	http://library.com/books/
	http://library.com/books/{book} 
	http://library.com/findBookForm
	http://library.com/authors/
	http://library.com/authors/{author}
	http://library.com/findAuthorForm			
			
			

Dans ce cas voilà comment le client peut accéder à l'application :

	bookResource = new Resource('http://library.com/books/001')
	bookResource.delete()					
			

On observe bien l'intérêt d'avoir une interface uniforme qui permet aux clients d'accéder à des données provenant d'un éventail de ressources, sans code spécial pour traiter chacunes, tant qu'elle est uniforme.
A l'inverse on peut avoir qu'une implémentation basée sur RPC est très dépendante de l'application et des objets à exposer.

REST vs SOAP

Il s'agit ici d'opposer Ressources et Services.

L'objectif d'une architecture orientée ressources est de s'aligner sur les technologies qui existent déjà à savoir : HTTP, URI et XML.
Tandis qu'une approche par services est plutôt influencée par une logique d'entreprise et se base sur plusieurs technologies en même temps (SOAP + WSDL + UDDI + WS_*). Ce qui peut nous amener à nous poser la question où se trouve le Web dans ces Web Services ?

Les services web SOAP/WS_* permettent d'obtenir des fonctionnalités avancées mais rendent les applications moyennement interopérables. Ils sont plus adaptés pour des échanges "server to server" car orientés traitement avec plusieurs interfaces spécialisées.

Les services web orientés données avec une interface uniforme générique permet moins de contrôle mais offre plus simplicité et de possiblités de réutilisation.