REST: Re­pre­sen­ta­tio­nal State Transfer

Das World Wide Web besteht aus weit mehr Kom­po­nen­ten, als In­ter­net­nut­zer beim Aufruf einer Website oder -ap­pli­ka­ti­on wahr­neh­men. So greifen bei­spiels­wei­se nicht nur mensch­li­che User, sondern auch ma­schi­nel­le Benutzer auf die Daten und Inhalte ver­schie­dens­ter Web­pro­jek­te zu. Die Vor­aus­set­zung ist, dass der jeweilige Betreiber sein Projekt überhaupt anderen An­wen­dun­gen zu­gäng­lich macht, indem er einen ent­spre­chen­den Web­ser­vice zur Verfügung stellt. Ein gutes Beispiel stellt der Kurz­nach­rich­ten­dienst Twitter dar: Dank eines ent­spre­chen­den Web­ser­vices können beliebige An­wen­dun­gen Tweets im Namen eines Twitter-Users auslesen oder gar schreiben.

Um einen solchen Web­ser­vice zu im­ple­men­tie­ren, gibt es ver­schie­de­ne Techniken wie das Ab­fra­ge­pro­to­koll Remote Procedure Call (RPC), das Netz­werk­pro­to­koll SOAP oder auch das Pro­gram­mier­pa­ra­dig­ma Re­pre­sen­ta­tio­nal State Transfer (REST), um das es im Folgenden geht.

Der Begriff „Re­pre­sen­ta­tio­nal State Transfer“ stammt aus einer von 2000 da­tie­ren­den Dis­ser­ta­ti­on von Roy Fielding, einem der Haupt­ent­wick­ler zahl­rei­cher Web­stan­dards. Er be­schreibt in abs­tra­hier­ter Form die Ar­chi­tek­tur, die dem World Wide Web (HTTP-Protokoll, HTML- und XML-Parser, Web- und Ap­pli­ca­ti­on-Server etc.) zugrunde liegt. Prin­zi­pi­ell ist die REST-Ar­chi­tek­tur al­ler­dings nicht von spe­zi­fi­schen Pro­to­kol­len abhängig. Ihr zentrales Konzept sind Res­sour­cen, die nach Fielding folgende An­for­de­run­gen erfüllen müssen:

• Adres­sier­bar­keit: Jede Ressource, z. B. eine Be­stel­lung, ein Produkt oder ein Artikel, muss über einen Unique Resource Iden­ti­fier (URI) iden­ti­fi­ziert werden können.

• Ein­heit­li­che Schnitt­stel­le: Auf jede Ressource muss einfach und ein­heit­lich mithilfe von Stan­dard­me­tho­den zu­ge­grif­fen werden können. Beispiele sind HTTP-Methoden wie „GET“, „POST“ oder „PUT“.

• Client-Server-Struktur: Generell gilt das Client-Server-Prinzip, nach dem ein Server einen Dienst zur Verfügung stellt, der bei Bedarf von einem Client an­ge­for­dert werden kann.

• Zu­stands­lo­sig­keit: Die Kom­mu­ni­ka­ti­on zwischen Server und Clients ist zu­stands­los. Das heißt, dass alle aus­ge­tausch­ten Nach­rich­ten sämtliche In­for­ma­tio­nen enthalten, die notwendig sind, um sie zu verstehen. Der Server speichert keine Zu­satz­in­for­ma­tio­nen zwischen zwei Nach­rich­ten wie bei­spiels­wei­se in Form von Sessions. Die Zu­stands­lo­sig­keit macht REST-Services sehr einfach ska­lier­bar, da ein­ge­hen­de Anfragen im Rahmen von Last­ver­tei­lung un­kom­pli­ziert auf ver­schie­de­ne Server verteilt werden können.

• Un­ter­schied­li­che Re­prä­sen­ta­tio­nen der Res­sour­cen: Jede Ressource kann un­ter­schied­li­che Dar­stel­lungs­for­men besitzen. Je nachdem, was der Client anfordert, muss sie bei­spiels­wei­se in ver­schie­de­nen Sprachen oder Formaten wie HTML, JSON oder XML aus­ge­lie­fert werden können.

• Hy­per­me­dia: Die Be­reit­stel­lung der Res­sour­cen geschieht über Hy­per­me­dia, z. B. in Form von „href“- und „src“-At­tri­bu­ten in HTML-Do­ku­men­ten oder für die jeweilige Schnitt­stel­le de­fi­nier­ten JSON- bzw. XML-Elementen. Somit navigiert der Client einer REST-API nach dem Prinzip „Hy­per­me­dia as the Engine of Ap­pli­ca­ti­on State (HATEOAS)“ aus­schließ­lich über URLs, die der Server be­reit­stellt und benötigt kein zu­sätz­li­ches Wissen über die Schnitt­stel­le.

Diese strikten Vorgaben der REST-Ar­chi­tek­tur er­mög­li­chen die Ent­wick­lung gut struk­tu­rier­ter Dienste, die einfach zu in­te­grie­ren sind und über ein ein­heit­li­ches Protokoll (HTTP) kom­mu­ni­zie­ren. Dank der res­sour­cen­ori­en­tier­ten Struktur entfällt bei der Kon­zi­pie­rung eines REST-Web­ser­vices außerdem die Suche nach an­wen­dungs­spe­zi­fi­schen Pro­to­kol­len, die bei ver­gleich­ba­ren Al­ter­na­ti­ven wie SOAP notwendig ist.

Um einen REST-Web­ser­vice zu rea­li­sie­ren, werden haupt­säch­lich HTTP und dessen ver­schlüs­sel­te Version HTTPS verwendet. Das ist ei­ner­seits auf dessen enorme Ver­brei­tung zu­rück­zu­füh­ren, dank der es in so gut wie jeder Firewall offen ist; an­de­rer­seits ist das zu­stands­lo­se Hypertext Transfer Protocol auch ver­gleichs­wei­se einfach aufgebaut, ohne dass spezielle Im­ple­men­tie­run­gen vor­aus­ge­setzt werden. Zudem definiert der HTTP-Standard bereits ein ganzes Set an Befehlen, mit denen auf Res­sour­cen zu­ge­grif­fen werden kann:

Die Be­fehls­pa­let­te kann durch die Im­ple­men­tie­rung weiterer Pro­to­kol­le ver­grö­ßert werden. Typisch ist hier vor allem das WebDAV-Protokoll, das die Methoden COPY (Ressource kopieren), MOVE (Ressource ver­schie­ben), LOCK (Ressource sperren), UNLOCK (Ressource freigeben) und MKCOL (Ver­zeich­nis erstellen) hinzufügt.

Das REST-Gerüst liefert her­vor­ra­gen­de Mittel zur Kon­zi­pie­rung und Umsetzung von Web­ser­vices ver­schie­dens­ter Art. Dank der Tatsache, dass nahezu alle Geräte das Hypertext Transfer Protocol un­ter­stüt­zen, können sowohl Desktop- als auch mobile Clients mühelos und ohne zu­sätz­li­che Im­ple­men­tie­run­gen mit dem REST-Interface arbeiten. Das Ergebnis sind Web­ser­vices, die durch ein hohes Maß an

• Platt­form­un­ab­hän­gig­keit,

• Ska­lier­bar­keit,

• Per­for­mance,

• In­ter­ope­ra­bi­li­tät

• und Fle­xi­bi­li­tät

über­zeu­gen. Die Nutzung erfordert jedoch auch das ent­spre­chen­de Know-how, wobei vor allem die In­ter­ak­ti­on zwischen den einzelnen, zu­stands­lo­sen Res­sour­cen sehr komplex und schwer zu be­werk­stel­li­gen ist. Wer bereits mit Al­ter­na­ti­ven wie dem Protokoll SOAP ge­ar­bei­tet hat, wird durch die gänzlich anderen und un­ge­wohn­ten Ansätze zum Umdenken gezwungen sein – besitzt am Ende aber einen Service, der sehr viel leichter in un­er­war­te­ten Kontexten nutzbar ist.