2

REST – und das Interface gehört Dir!

Posted Februar 7th, 2011 in Blog by Jonas Soukup

REST – und das Interface gehört Dir!

REST ist keine neue Architektur oder Programmiersprache, sondern eher ein “Style”, der sich für das Design von Serverinterfaces für connected mobile Apps gut eignet:

    • Informationen, Funktionen und Daten werden dabei mit Standardmitteln (Protokoll: HTTP inkl. Standard-Statuscodes, Methoden GET, DELETE, PUT, POST) auf einfache Weise und ohne Overhead als Ressourcen (addressierbar über URIs) bereitgestellt.
    • Typische REST URI: http://creativeworkline.com/server/rest/service/v1/companies
    • Daten werden beim REST Stil immer in Form von Repräsenationen übertragen (z.B als XML oder JSON Dokument, welche leicht von den mobilen Clients geparsed und verarbeitet werden können).
    • Komposition von Komponenten: Ein REST Interface ist “loosly coupled”,  von einer Ressource zur anderen kann über Hyperlinks navigiert werden (z.B. antwortet der Server auf eine Client-Anfrage mit einem Location Header oder mit einem Standard 303 Status Code [see other (z.B. für load balancing)]).

  • Bei REST liegt die Anwendugsstatusverantwortung beim Client (Wo in der App befinde ich mich gerade? / State-Machine), die Resourcenverantwortung (URI Parameter, Skalierung, Versionierung, Lastverteilung etc.) beim Server. Dies macht insbesondere in einem Setup mit mobilen Clients (Android, iPhone Apps) Sinn.
  • Ein REST Interface ist zur bestehenden Web Infrasturkur gut kompatibel und zukunftssicher.
  • REST Interfaces sind einfach versionierbar (z.B: /tld-domain/v1/items und /tld-domain/v2/items).
  • Ein herausragender Pluspunkt von REST ist die Skalierung und Performanz:
    • Caching: Durch das Setzen auf Standardtechnologien (HTTP und dessen Cachingmechanismen), die sich auch beim unendlichen Wachstum des WWW bewährt haben, ist ein REST System sehr gut skalierbar. HTTP sieht Caching als integralen Bestandteil der Web-Infrastruktur an. Die HTTP Header dafür sind Expires oder Cache-Control: max-age. Zudem benutze Standard Proxy-Server (Man in the Middele) genau diese Funktionalität, was der Entwicklung dem exponentiellen Wachstums des Webs jedenfalls zuträglich war.
    • Die Stateless-Natur des HTTP Protokolls setzt voraus, dass alle nötigen Informationen in einem Request übertragen werden. Es gibt kein “Session-Handling” am Server. Dadurch kann jeder Request auch von jedem beliebigen Server verarbeitet werden (Load-Balancing, Ausfallsicherheit).

In Wikipedia ist darüber hinaus zu lesen:

Der Begriff Representational State Transfer (mit dem Akronym REST) bezeichnet einen Softwarearchitekturstil für verteilte Hypermedia-Informationssysteme wie das World Wide Web. Während dessen Architektur durch den URI-Standard und HTTP beschrieben werden kann, legt der REST-Architekturstil nahe, jede Ressource mit einer eigenen URI anzusprechen.
REST stammt aus der Dissertation von Roy Fielding aus dem Jahre 2000, in der er den Erfolg des World Wide Webs auf bestimmte Eigenschaften der verwendeten Mechanismen und Protokolle (z. B. HTTP) zurückführt. Fielding war zuvor auch an der Spezifikation des Hypertext-Transfer-Protokolls (HTTP) beteiligt.
Der Begriff wird auch im weiteren Sinne verwendet, um grundsätzlich einfache Schnittstellen zu kennzeichnen, die Daten über HTTP übertragen, ohne etwa eine zusätzliche Transportschicht wie SOAP oder Sitzungsverwaltung über Cookies einzusetzen.
REST gilt in seiner Konsequenz als eine wichtige Richtlinie für die Nutzung von Web-Standards, in Abgrenzung zu vielen historisch gewachsenen Verfahren. Daraus folgt teils eine Rückbesinnung auf grundlegende Web-Technologien, die die Implementierung verteilter webbasierter Systeme vereinfachen soll.

Der REST Stil

  • Die Kommunikation erfolgt auf Abruf. Der Client ist aktiv und fordert vom passiven Server eine Repräsentation an, bzw. modifiziert eine Ressource.
  • Ressourcen, die Objekte der Anwendung, besitzen eine ihnen zugeordnete URI, mit der sie adressiert werden können.
  • Die Representation einer Resource kann als Dokument vom Client angefordert werden.
  • Repräsentationen können auf weitere Resourcen verweisen, die ihrerseits wieder Repräsentationen liefern, die wiederum auf Resourcen verweisen können (Konzept der Hyperlinks).
  • Der Server verfolgt keinen Clientstatus. Jede Anfrage an den Server muss alle Informationen beinhalten, die zum Interpretieren der Anfrage notwendig sind. (Stateless, Vorraussetzung für Skalierung)
  • Caches werden unterstützt. Der Server kann seine Antwort als Cache fähig oder nicht Cache fähig kennzeichnen.

REST Methoden – Empfohlener und typischer Einsatz

Es folgt eine Auflistung von Standard HTTP Methoden und deren typischer Einsatz (Best-Practice).

Method Typical Usage Typical Status Codes Safe? Ind.
GET ‐ retrieve a representation
‐ retrieve a representation if modified (caching)
  • 200 (OK) ‐ the representation is sent in the response
  • 204 (no content) ‐ the resource has an empty representation
  • 301 (Moved Permanently) ‐ the resource URI has been updated
  • 303 (See Other) ‐ e.g. load balancing
  • 304 (not modified) ‐ the resource has not been modified (caching)
  • 400 (bad request) ‐ indicates a bad request (e.g. wrong parameter)
  • 404 (not found) ‐ the resource does not exits
  • 406 (not acceptable) ‐ the server does not support the required representation
  • 500 (internal server error) ‐ generic error response
  • 503 (Service Unavailable) ‐ The server is currently unable to handle the request
yes yes
DELETE ‐ delete the resource
  • 200 (OK) ‐ the resource has been deleted
  • 301 (Moved Permanently) – the resource URI has been updated
  • 303 (See Other) ‐ e.g. load balancing
  • 400 (bad request) ‐ indicates a bad request 404 (not found) ‐ the resource does not exits 409 (conflict) ‐ general conflict
  • 500 (internal server error) – generic error response
  • 503 (Service Unavailable) ‐ The server is currently unable to handle the request
no yes
POST ‐ create a resource with server‐side managed (auto generated) instance id‐ create a sub‐resource‐ partial update of a resource‐ partial update a resource if not modified (optimistic locking)
  • 200 (OK) ‐ if an existing resource has been updated 201 (created) ‐ if a new resource is created
  • 201 (created) ‐ if a new resource is created
  • 202 (accepted) ‐ accepted for processing but not been completed (Async processing)
  • 301 (Moved Permanently) ‐ the resource URI has been updated
  • 303 (See Other) ‐ e.g. load balancing
  • 400 (bad request) ‐ indicates a bad request
  • 404 (not found) ‐ the resource does not exits
  • 406 (not acceptable) ‐ the server does not support the required representation
  • 409 (conflict) ‐ general conflict
  • 412 (Precondition Failed) e.g. conflict by performing conditional update
  • 415 (unsupported media type) ‐ received representation is not supported
  • 500 (internal server error) ‐ generic error response
  • 503 (Service Unavailable) ‐ The server is currently unable to handle the request
no no
PUT ‐ create a resource with client‐side managed instance id‐ update a resource by replacing‐ update a resource by replacing if not modified (optimistic locking)
  • 200 (OK) ‐ if an existing resource has been updated
  • 201 (created) ‐ if a new resource is created
  • 301 (Moved Permanently) ‐ the resource URI has been updated
  • 303 (See Other) ‐ e.g. load balancing
  • 400 (bad request) ‐ indicates a bad request
  • 404 (not found) ‐ the resource does not exits
  • 406 (not acceptable) ‐ the server does not support the required representation
  • 409 (conflict) ‐ general conflict
  • 412 (Precondition Failed) e.g. conflict by performing conditional update
  • 415 (unsupported media type) ‐ received representation is not supported
  • 500 (internal server error) – generic error response
  • 503 (Service Unavailable) ‐ Theserver is currently unable to handle the request
no yes

 

Beispiel REST Request & Response (Standard HTTP!)

In diesem Beispiel ruft der Client mit einem Standard GET Request Informationen zum Objekt “hotel” mit der ID 656bcee2-28d2-404b-891b ab, der Server antwortet in diesem Fall mit einerm URL encoded Key-Value Pair String im Body.
REQUEST:

GET /hotel/656bcee2-28d2-404b-891b HTTP/1.1
Host: localhost
User-Agent: xLightweb/2.6

RESPONSE:

HTTP/1.1 200 OK
Server: xLightweb/2.6
Content-Length: 277
Content-Type: application/x-www-form-urlencoded
classification=Comfort&name=Central&RoomURI=http%3A%2F%2Flocalhost%2 Fhotel%2F
656bcee2-28d2-404b-891b%2FRoom%2F2&RoomURI=http%3A%2F%2Flocalhost%2F hotel%2F6
56bcee2-28d2-404b-891b%2FRoom%2F1

Die Entwicklung von REST Services und der Test ist auch mit Standard Firefox Add-Ons recht einfach zu bewerkstelligen (z.B. mit AddOn RESTClient https://addons.mozilla.org/en-US/firefox/addon/9780/)

Abgrenzung REST und SOAP

REST = Architektur-Stil für das Web
SOAP = SOA Middleware, Interoperabilität, Standards

  • Vorteile SOAP
    • Intuitive Umsetzung von Services
    • Große Freiheit bei der Umsetzung
    • Strenges “Type-Checking”, sehr formelle “Contracts” zwischen Provider und Consumer
    • Unterstützung von “stateful” Operationen
  • Nachteile SOAP
    • Nur „zugeschnittene“ Clients können Request/Responses verarbeiten
    • Zusätzlicher Overhead durch XML
  • Vorteile REST
    • Unabhängigkeit der Clients
      • Lediglich die Unterstützung von HTTP muss gewährleistet sein
    • Skalierbarkeit der Dienste
    • “Lightweight”, kein extra XML Markup
    • Menschenlesbare Resultate
    • Einfach zu entwickeln, keine Toolkits werden benötigt
    • Caching möglich da “stateless”
  • Nachteile REST
    • Fehlende Standardisierung
    • REST oft falsch verstanden
    • Schwierige Abbildung der Anwendungsfunktionalität auf Ressourcen

Unterstützung in mobile Clients

  • HTTP
    • Auf praktisch allem Mobilfunkplattformen wird HTTP unterstützt
    • „Nur“ HTTP über TCP, jedoch muss auch HTTP über UDP möglich sein
  • SOAP
    • Vereinzelte Unterstützung
      • Symbian: ja
      • Android: nein
      • iPhone: nein
    • Viele kleinere Projekte für verschiedene Plattformen
      • Nur als Client
      • HTTP über TCP
  • REST
    • Unterstützung von Haus aus nicht gegeben
    • Lediglich Unterstützung von HTTP benötigt
      • Diese aber sehr umfangreich
  • „Freiheit“ bei der Wahl der Clients
    • SOAP: ausschließlich zugeschnittene Clients
    • REST: potenzielle Clients müssen lediglich HTTP unterstützen (Browser, AJAX)
  • Overhead
    • SOAP: HTTP + SOAP
    • REST: HTTP

Einsatz von REST

REST APIs sind weit verbreitet und der Defacto-Standard:

Industrie

REST – Fazit

REST – Und das Interface gehört dir! Wir empfehlen REST als “Style” für die Entwicklung einer mobilen API, da

  • es der de-facto Industriestandard ist
  • die Alternative SOAP durch die Envelopes einen zu großen Overhead erzeugt, welcher sich auf die Performance auswirkt
  • REST ohne den Overhead WSDL (Web Service Description Language bei SOAP) auskommt, und die Entsprechung WADL (Web Application Description Language) später bei Bedarf hinzugefügt werden kann
  • HTTP Standards für Kompatibilität, Ausfallsicherheit und Skalierung sprechen
  • wir damit sehr gute Erfahrungen haben und für viele eigenen vernetzen mobilen Apps REST Serverschnittstellen verwenden (bis eine bessere Technologie REST ablöst)
  • externe Komponenten und speziell mobile Clients dafür lediglich HTTP und XML oder JSON sprechen können müssen
  • REST unabhängig von der verwendeten Implementierungstechnologie des Servers eingesetzt werden kann
  • Android und iPhone Clients gerne “REST” sprechen

 

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

2 Responses so far.

  1. Mateusz sagt:

    Cooler Artikel!

    Vielleicht gibts bald eine API (u.A. RESTful) von der Telekom Austria gratis. Zur Zeit läuft eine Poll darüber welche für Developer am interessantesten wäre.

    http://creatingapps.telekomaustria.com/which-api-is-most-interesting-for-you-poll-tag.html

    LG
    Mateusz

  2. Klemens Zleptnig sagt:

    Danke für den Link. RESTful ist auf alle Fälle der richtige Weg.

Leave a Reply





Share:  
Mobile App Entwicklung und App Programmierung in Deutschland und Österreich. © App Agentur creative workline GmbH GmbH 2014
  App Entwicklung Berlin App Entwicklung Köln App Entwicklung München App Entwicklung Frankfurt App Entwicklung Hamburg App Entwicklung Hannover App Entwicklung Bremen App Entwicklung Düsseldorf App Entwicklung Deutschland App Entwicklung Wien App Entwicklung Österreich
  App Programmierung Berlin App Programmierung Köln App Programmierung München App Programmierung Hamburg App Programmierung Hannover App Programmierung Bremen App Programmierung Deutschland App Programmierung Wien App Programmierung Österreich