RESTful Web-Services mit Qualität: Teil 1: Mit Best Practices zu einem qualitätsorientierten Entwurf

Transkript

1 RESTful Web-Services mit Qualität: Teil 1: Mit Best Practices zu eiem qualitätsorietierte Etwurf RESTful Web-Services mit Qualität: Teil 1: Mit Best Practices zu eiem qualitätsorietierte Etwurf Der Tred, Web-Services auf der Basis vo REST umzusetze, ist ugebroche. Die steigede Popularität vo REST schlägt sich auch i der Azahl a Frameworks ieder, die de Eistieg i die Etwicklug vo RESTful Web-Services zusätzlich vereifache. Die zuehmede Verbreitug vo REST ud der damit verbudee Eifluss auf die Qualität eier gesamte Architektur erforder es daher, die Qualität vo RESTful Web-Services stärker als bisher zu betrachte. Dieser Artikel fasst Best Practices für RESTful Web-Services zusamme, die berücksichtigt werde sollte, um Aforderuge a eie qualitativ hochwertige Architektur gerecht zu werde. Besteht i eiem Projekt die Aforderug, Web-Services zu etwickel, so fällt die Etscheidug heutzutage häufig auf REST als Paradigma (vgl. [If11]). Meist sid die Grüde hierfür, dass REST im Vergleich zu alterative Asätze wie Web-Services auf Basis vo SOAP eie gerigere Komplexität aufweist ud eie leichtgewichtigere Übertragug vo Date ermöglicht. Zusätzlich ist die große Fuktiosvielfalt vo SOAP i ur weige Projekte tatsächlich erforderlich. Die zuehmede Verwedug vo REST i Projekte bedeutet jedoch, dass der Eifluss vo REST auf die gesamte Architektur stark zugeomme hat. Es gilt daher mehr de je, die Gestaltug vo Web-Services auf Basis vo REST mit besoderer Sorgfalt durchzuführe ud dem qualitätsorietierte Etwurf vo RESTful Web-Services eie wesetliche Rolle zukomme zu lasse, um eie hohe Qualität der gesamte Architektur sicherzustelle. Aufgrud des große Gestaltugsspielraums beim Etwurf vo RESTful Web- Services wurde i de letzte Jahre sowohl seites der Forschug als auch der Idustrie diverse Best Practices erarbeitet, die diese Gestaltugsspielraum weiter eischräke ud Empfehluge gebe, wie ei qualitativ hochwertiger RESTful Web- Service gestaltet werde sollte. Für Architekte ud Etwickler ergebe sich hierbei drei wesetliche Herausforderuge: Bei REST (REpresetatioal State Trasfer) hadelt es sich um eie Architekturstil, der vo Fieldig (vgl. [Fie00]) im Rahme seier Dissertatio etwickelt wurde. Als Grudlage für de Etwurf vo REST idetifizierte Fieldig zuächst vier Schlüsseleigeschafte der WWW-Architektur, die für de Erfolg des Web veratwortlich ware. Um diese Eigeschafte zu erfülle, leitete er sechs Restriktioe ab, die heute die Grudpfeiler vo REST darstelle. Heutzutage wird ei Web-Service, der diese Restriktioe berücksichtigt, als RESTful bezeichet. Dabei verwaltet ei RESTful Web- Service eie oder mehrere Ressource, mit dee über Repräsetatioe iteragiert werde ka. Die Kozepte ud ihre Zusammehäge sid i Abbildug 1 dargestellt. Kaste 1: Die Etstehug vo REST. Kostegrüde icht vollstädig berücksichtigt werde köe. Die Überprüfug, ob die Best Practices eigehalte wurde, erfordert zuächst die Übertragug auf die jeweils geutzte Techologie, wie beispielsweise JAX- RS im Java-Umfeld. Die Überprüfug selbst geht zusätzlich mit eiem hohe mauelle Aufwad eiher ud ist somit aufgrud der Komplexität heutiger Systeme fehlerbehaftet. Wir werde zeige, wie Architekte ud Etwickler diese Herausforderuge systematisch agehe ud RESTful Web-Services i Projekte effiziet prüfe köe. Hierfür Best Practices sid heutzutage i verschiedee Literaturquelle beschriebe. Das heißt, i eiem erste Schritt müsse diese Quelle gefude, die jeweilige Beschreibug iterpretiert ud eie eiheitliche Mege a Best Practices abgeleitet werde. Gegebeefalls müsse Best Practices priorisiert werde, da sich diese etweder gegeseitig ausschließe oder aus Abb. 1: Kozepte vo REST. 28

2 schwerpukt Tipp 4: Abahmetests sollte immer grü sei Zero Bug Policy. Iteratio kapp wird. Das führt zu eiem Auch we das Release och ei paar Woche gefährliche Trugschluss: We es akzeptabel ist, mauelle Tests im Notfall wegzu- etfert sei mag, ist es sehr wichtig, Testfälle icht läger als otwedig fehlschlage zu lasse lasse, sid sie scheibar icht wichtig. auch we ma die vermutliche Ursache ket. Auch i der agile Welt ist es der Zweck Ei fehlschlageder Testfall ka durchaus vo Tests, Fehler i der Software zu fide. Probleme verdecke, die erst ach Behebug der We automatisierte Tests dazu ur offesichtliche Ursache zu Tage trete. Ziel des bedigt i der Lage sid, gibt es lediglich Teams muss es sei, die Testfälle auch währed eie Alterative: mauelles beziehugsweise exploratives Teste, bei dem die der Etwicklug grü zu halte. Grü bezieht sich hier auf die Sigalfarbe, die traditioell i Build- Tester ihre Kreativität ud Spotaität eisetze, um Fehler zu fide. Ei weset- Umgebuge eigesetzt werde. licher Nutze maueller Tests besoders bei eue Features ist die kotextbezogee Perspektive auf die zu prüfede gehesweise, we die Erweiterug durch Fuktioalität. De im Gegesatz zu Umpriorisierug doch icht stattfidet ud automatisierte Tests ket der mauelle die Tests weiterhi mauell durchgeführt Tester dere aktuelle Kotext. werde müsse. We es Kude ud Budget zulasse, Aus userer Erfahrug loht sich eie plae wir am Ede eier Iteratio für alle sprechede, achvollziehbare Zuordug Etwickler eie Tag ei, desse Fokus auf Abb. 2: Keie Vermischug des Numerus bei der Bezeichug der Ressource. vo Aforderuge (User-Storys) ud maueller Testdurchführug liegt. Ziel dieses Tages ist es, die Software zerbreche zu Akzeptaztests. Wird eie Aforderug verädert oder erweitert, fließt der Auf - lasse. Geligt es, de Code durch Beut - wad für eie otwedige Apassug zer eigabe oder Datekostellatioe zu besteheder Akzeptaztests mit i die zerbreche, wird für die Situatio, die dazu Schätzug ei. Gibt es außerhalb des geführt hat, ei automatisierter Test stelle wir im erste Teil dieses zweiteilige Versioierug Etwicklugsteams Iteressete für die geschriebe. Aschließed wird der Ma - Artikels eie Mege a Best Practices vor, die Eie Versioierug ist gemäß Bria Mulloy Akzeptaztest-Kriterie, erhalte diese gel ach voll ziehbar behobe ud mit dem für de Etwurf vo RESTful Web-Services (vgl. [Mul12]) eie der wichtigste Betrachtuge beim Etwurf eies Web-Service, wertvolles Feedback zu de Auswirkuge automatisierte Test dafür gesorgt, dass die relevat sid ud dere Qualität beeiflusse (Herausforderug 1). Die Best Practices weshalb desse Schittstelle (achfolged der Äderug. Köe Aforderuge ud so ge woee höhere Robustheit erhalte Akzeptaztests eiader icht zugeordet bleibt. stamme dabei aus besteheder Literatur als Web-API bezeichet) iemals ohe eie werde, kommt das böse Erwache bei der ud vereiheitliche diese. Versioserkeug veröffetlicht werde Etwicklug: Die Äderuge dauer füf Plädoyer für Nicht- Um eie Priorisierug der Best Practices zu ermögliche (Herausforderug 2), vo Fieldig: Versioig a iterface is sollte. Dem gegeüber steht die Aussage Miute, das Apasse der fehlgeschlagee alte Akzeptaztests zwei Tage. We die geforderte Fuktioalität imple- Automatisierug werde wir im zweite Teil des Artikels just a polite way to kill deployed applicatios (vgl. [Fie13]). Durch das Prizip vo metiert wurde, also sämtliche automatisierte Tests durchgeführt ud um evetuell die Best Practices mit Qualitätsmerkmale wie Wartbarkeit ud Effiziez aus der Hypermedia As The Egie Of Applicatio Mauelle Tests Mauelle Tests sid auch i agile Pro - otwedige mauelle Tests der eue ISO/IEC 25010:2011 (vgl. [ISO]) verküpfe. Zusätzlich werde wir zeige, wie auf Service mit eier herkömmliche Web-Seite State (HATEOAS) ka ei RESTful Webjekte wichtig. Sie schließe die Lücke zwische automatisierte Tests ud aufwädig weitere mauelle Stufe a. Features ergäzt wurde, schließt sich eie Basis der Ergebisse vo Michael Gebhart vergliche werde, wodurch eie Versioierug obsolet wird. Dies setzt atürlich oder gar icht automatisiert prüfbare Der User-Acceptace-Test (UAT) diet (vgl. [Geb11]) eie Automatisierug durch Aforderuge. Dabei köe mauelle dazu, eie Software uter reale Bedi gu - Werkzeuge erfolge ka. Um die Ergebisse i Projekte eizusetze, stelle wir Etwicklug des Web-Service als auch bei voraus, dass HATEOAS sowohl bei der Tests zeitaufwädig ud fehlerafällig sei. ge zu teste ud zu prüfe, ob eie Auch i der agile Welt eige Projekt - Software effiziet ud effektiv geutzt werde ka. Software, die für Edaweder im zweite Teil eie Bewertugsboge desse Diestehmer berücksichtigt wird. teams dazu, mauelle Tests zu verachlässige, we die Zeit am Ede eier gedacht ist, muss bei dieser Testart vom zum Dowload bereit, mit dem RESTful Web-Services i Projekte systematisch geprüft werde köe. Beschreibug vo Ressource Beutzer selbst geprüft werde. Dazu ist es otwedig, de fachliche Kotext der zu Tipp 5: Pair-Testig im UAT. Die Beschreibug vo Ressource ist für prüfede Soft ware zu kee ud eizu- User-Acceptace-Tests sollte dabei ie die Beutzbarkeit eies Web-Service et- Best durch Practices die Softwareetwickler für RESTdurchge- führt werde. gibt UAT es eie mittels Vielzahl Pair-Testig a hat uter- Für REST schiedliche sich dagege Best bewährt. Practices, Hier die führt wir eiach- folged Beutzer beleuchte de UAT wolle. durch, der Wir Etwickler gruppiere hierzu sitzt die daebe gesammelte ud bekommt Best direkt Practices wertvolles Feedback zur Kategorie Beutzbarkeit ud seier setze i acht verschiedee die Nutzug Arbeit. Im Idealfall des Awedugsprotokolls ist dieser Tester der Hypertext Kude selbst Trasport oder ei Mitarbeiter Protocol mit (HTTP) tiefem fachliche Wisse, (vgl. [RFC2616]) für die aber achfolgede keie weitere Ketisse Betrachtug voraus. über de Quellcode. OBJEKTspektrum ist eie Fachpublikatio des Verlags: SIGS DATACOM GmbH Lidlaustraße 2c Troisdorf Tel.: / Fax: / ifo@sigs-datacom.de beziehe. Test werk zeuge sid hierzu icht scheided, da die Ressource die Domäe i der Lage. Aus userer Sicht ist ei vollstädig automatisierter UAT auch i der abbilde. Hierfür kote wir folgede sechs Best Practices idetifiziere: agile Welt icht seriös durchführbar ausgeomme automatisierte Smoke-Tests, die Für die Bezeichug vo Ressource die Vollstädigkeit der Fuk tio alität oberflächlich prüfe. Gele getlich werde auto- sollte Nome verwedet werde, da dies eie etablierte Kovetio darstellt matisierte GUI-Tests (Graphi cal-user- (vgl. [Mul12], [Vi08], [Pa14]). Iterface) als UAT bezeichet. Diese Tests Die Ressource sollte domäespezifisch ud kokret beat sei, sodass sid fuktioale Tests uter Eibeziehug eier Oberfläche ud köe zum Beispiel dere Bedeutug abgeleitet werde im Regressiostest eie wertvolle Beitrag ka (vgl. [Jau14], [Pa14]). leiste. Sie sid aber kei Er satz für die Die Azahl der Ressource sollte zwische 12 ud 24 liege, um so die Kom- Eibeziehug des Mesche als Tester. plexität des Systems zu begreze (vgl. [Mul12]). Dadurch muss uter Umstäde Tipp 6: ei Zeitaher Kompromiss UAT. zwische der Bezeichug Währed der der UAT Ressource i der klassische ud dere Azahl Projektwelt eigegage eie abgeschlossee werde. Phase Auf darstellt, die Vermischug bietet es sich i des agile Numerus Projekte bei der a, Bezeichug umittelbar ach vo dem Ressource Abschluss eier sollte verzichtet Fuktioalität werde, Nutzer-Feedback währed gleichzeitig eizuhole. eie Präferez Will der für Etwickler die Pluralform i Folge des ausgesproche Feedbacks wird Äderuge (siehe Abbildug vorehme, 2). ist seie Arbeit effektiver als ach eiem Vergleichbar mit Klasse bei der Objektorietierug köe auch Res- UAT-Feedback mehrere Woche. source Attribute ethalte. Für dere Bezeichug sollte die Biemajuskel- Ei Fokus des UAT liegt auf der Istal - oder auch Kamelhöcker-Schreibweise lierbarkeit der Software. Diese lässt sich mit führedem Kleibuchstabe verwedet werde, welche sich auch i leicht i Kombiatio mit der obe beschriebee automatisierte Prüfug auf der Programmierug etabliert hat (vgl. Vollstädigkeit awede: We dieser [Mul12]). Smoke-Test erfolgreich war, ließ sich die Da der Medietyp JavaScript Object Software offebar erfolgreich istalliere. Notatio (JSON) immer häufiger bei der Ziel des UAT ist es, die Beutzbarkeit eier Iteraktio mit Web-Services eigesetzt Software zu prüfe. Aus eigeer Erfahrug wird, sollte bei der Bezeichug der Attribute die Nameskovetioe vo Ja- wisse wir, dass für eie erfolgreiche UAT i alle Teststufe gewissehaft gearbeitet vascript beachtet werde (vgl. [Mul12]). werde muss. Für Et wickler gibt ichts Schlimmeres als eie UAT, der vo de Tester oder vom Kude ach weige Idetifizierug vo Ressource Miute abgebroche wird, weil viele offesichtliche Fehler i de vorherige Teststufe Die Idetifizierug vo Ressource erfolgt gemäß Fieldig (vgl. [Fie00]) mithilfe eies icht etdeckt wurde ud der Software Uiform Resource Idetifier (URI). Hierfür magelde Qualität bescheiigt wird. kote wir die folgede vier Best Practices idetifiziere: Last ud Performace-Tests Die Teststufe Last- ud Performace-Tests Die URI sollte gemäß der Affordaz diet im Wesetliche dazu, drei ichtselbsterkläred sei (vgl. [Mul12]). 4 / /

3 RESTful Web-Services mit Qualität: Teil 1: Mit Best Practices zu eiem qualitätsorietierte Etwurf 1 SELECT * FROM r; 2 SELECT * FROM r WHERE uuid = i; Listig 1: Zwei SQL-Abfrage zum Abrufe vo Iformatioe eier Ressource r. Bei der Affordaz hadelt es sich um eie Desigeigeschaft, der zu Folge ei Gegestad ohe Erforderis eier Aleitug beutzt werde ka (vgl. [Mul12]). Da eie URI bei REST i der Regel aus Ressource besteht, spreche wir hier vo eier positive Korrelatio mit der kokrete ud domäespezifische Bezeichug eier Ressource (siehe Beschreibug vo Ressource, Pukt 2). Diese These kote durch die Utersuchug mehrerer bekater Web-Services, daruter Foursquare ud Twitter, belegt werde. Eie Ressource sollte lediglich über zwei URIs adressiert sei, wobei die erste eie Asammlug vo Zustäde eier Ressource r ud die zweite eie spezifische Zustad aus dieser Asammlug mithilfe eies Idetifikators i adressiert (vgl. [Mul12]). Dies ist vergleichbar mit eier Datebakabfrage gemäß Listig 1. Der Idetifikator zur Adressierug eies spezifische Zustads sollte ur schwer vorhersagbar sei, um so zum Beispiel eie ubeabsichtigte Dateverlust zu verhider (vgl. [Pap14]). Die Verwedug vo Verbe ierhalb eier URI gilt es zu vermeide, da dies eie methodeorietierte Asatz wie z. B. bei SOAP impliziere würde. Hierzu liefert Mulloy ei Beispiel, welche Auswirkuge ei derartiger Asatz mit sich brige würde (vgl. [Mul12]). Fehlerbehadlug Die Web-API repräsetiert de zetrale Zugagspukt eies RESTful Web-Service. Jegliche Iformatio zur Implemetierug des RESTful Web-Service wird durch diese verborge, wodurch lediglich das äußere Verhalte betrachtet werde ka. Das äußere Verhalte ergibt sich durch Rückmelduge des RESTful Web-Service. So müsse bei eiem Fehler die resultierede Fehlermelduge Aufschluss auf die Fehlerursache gebe, da zumeist kei Zugriff auf die Implemetierug des RESTful Web- Service existiert ud somit die übliche Techike zum Debugge icht awedbar sid. Um die Aussagekraft der Fehlermelduge sicherzustelle, kote wir drei Best Practices idetifiziere: Bei auftretede Fehler auf Seite des RESTful Web-Service sollte ach Stefa Jauker (vgl. [Jau14]), Steve Vioski (vgl. [Vi08]) ud Patroklos Papapetrou (vgl. [Pap14]) spezifische HTTP- Statuscodes a de Diestehmer übermittelt werde. Laut der derzeitige HTTP-Spezifikatio der IETF (vgl. [RFC2616]) ud [RFC6586]) existiere über 40 verschiedee HTTP-Statuscodes, vo dee viele RESTful Web-Services ur eie Teilmege utze. Nach [Mul12] 1 HTTP/ NOT FOUND 2 /* Weitere Header-Iformatioe */ 3 { 4 error : { 5 errorcode : 107, 6 messages : { 7 developer : Die ageforderte Ressource userd kote icht gefude werde. Meite Sie vielleicht users?, 8 user : Bei der Afrage ist leider ei Fehler aufgetrete. Bitte versuche Sie es och eimal zu eiem spätere Zeitpukt., 9 }, 10 additioalifo :.../docs/errors/107, 11 } 12 } Listig 2: Korrekte Fehlerbehadlug mit JSON. sollte icht mehr als acht verschiedee HTTP-Statuscodes verwedet werde, was im Widerspruch zur Aussage vo Jauker steht: We do t eed them all, but there should be used at least a mout of 10 (vgl. [Jau14]). Grudsätzlich ist die Azahl der HTTP- Statuscodes abhägig vom jeweilige RESTful Web-Service ud daher icht verallgemeierbar. Als Richtwert empfehle wir jedoch 8 bis 15 verschiedee HTTP-Statuscodes zu verwede, da es sich dabei aus userer Sicht zum eie um eie hadhabbare Mege hadelt ud zum adere bei der Utersuchug vo sechs verschiedee RESTful Web- Services sowohl der Durchschitt als auch der Media bei 12 HTTP-Statuscodes lag. Eie ausführliche Fehlerbeschreibug ist für das Verstädis der Fehlerursache vo zetraler Bedeutug. Aus diesem Grud sollte sowohl ach [Jau14] als auch ach [Mul12] eie Fehlerbeschreibug aus vier Bestadteile zusammegesetzt sei: 1) Eie Nachricht für de Etwickler, die die Fehlerursache beschreibt ud we möglich bereits Hiweise zur Lösug liefert. 2) Eie Nachricht für de Nutzer, die a diese weitergegebe werde ka. 3) Ei applikatiosspezifischer Fehlercode. 4) Ei Hyperlik, der auf weiterführede Iformatioe verweist (siehe Listig 2). Dokumetatio der RESTful Web-API Die Dokumetatio der Web-API zählt zu de umstritteste Artefakte im Kotext vo RESTful Web-Services, da diese eie zusätzliche Iformatio (out-of-bad iformatio) darstellt ud ach Roy T. Fieldig ubedigt zu vermeide ist: Ay effort spet describig what methods to use o what URIs of iterest should be etirely defied withi the scope of the processig rules for a media type (vgl. [Fie08]). Seie Aussage begrüdet Fieldig damit, dass eher die Dokumetatio die Art der Iteraktio leite würde als Hypermedia. So werde beispielsweise Hyperliks zu Ressource etspreched der Dokumetatio oftmals direkt i de Programmcode des Diestehmers eigebettet ud Geschäftsprozesse demetspreched umgesetzt. Eie Modifikatio der RESTful Web-API führt u im schlimmste Fall zu eiem icht fuktioierede Diestehmer. Diese 30

4 Umstad, bei dem die Dokumetatio das zetrale Artefakt bei der Etwicklug eies RESTful Web-Service darstellt, bezeiche wir als Documetatio As The Egie Of applicatio State (DATEOS). Zu beachte ist, dass a dieser Stelle explizit die Dokumetatio der Web-API gemeit ist, da lediglich die Web-API für de Edutzer sichtbar ist, icht jedoch die Implemetierug des Web-Service. Um dies zu vermeide, beötige wir für RESTful Web-Services eie eue Art vo Dokumetatio, die folgede Bestadteile aufweist: HTTP-Methode Seiteeffektfreiheit Idempotet POST Nei Nei GET Ja Ja PUT Nei Ja DELETE Nei Ja Tabelle 1: Eigeschafte der häufigste HTTP-Methode. Abb. 3: Abstraktes Ressourcemodell. Eiige Beispiele, wie ach dem Prizip vo HATEOAS mit dem RESTful Web- Service zu iteragiere ist, da viele Architekte ud Etwickler der Begriff HATEOAS icht bekat ist. Ei abstraktes Ressourcemodell i Form eies Zustadsdiagramms, das lediglich die Beziehuge der Ressource aufzeigt ud icht dere kokrete URIs (siehe Abbildug 3). Damit eihergehed sollte eie sematische Beschreibug der Ressource sowie dere Attribute erfolge, die sowohl vo Maschie als auch vo Mesche gelese werde ka. Ei Nachschlagewerk für auftretede Fehler (vgl. Kategorie Fehlerbehadlug ). Verwedug vo Parameter Viele RESTful Web-Services erweiter die URI eier Ressource, um optioale Iformatioe a eie Web-Service mithilfe vo Parameter zu übermittel (vgl. [Mul12]). Nachfolged behadel wir Awedugsbeispiele zum Filter, Sortiere, Selektiere ud Pagiiere vo Iformatioe, da diese vo eier Vielzahl a RESTful Web-Services uterstützt werde. Zur Filterug vo Iformatioe eier Ressource köe etweder dere Attribute oder eie spezielle Abfragesprache verwedet werde (vgl. [Jau14]). Die Wahl ist abhägig vo der ge- wüschte Mächtigkeit der Filterug. So sid eifache Filteruge über die Bezeichug der Attribute möglich, währed für komplexe Filteruge eie Abfragesprache erforderlich ist. Für das Sortiere vo Iformatioe empfiehlt Jauker (vgl. [Jau14]) de URI-Parameter sort, dem eie kommaseparierte Liste vo Attribute der Ressource mit jeweils führedem + für eie aufsteigede Sortierug oder - für eie absteigede Sortierug zugewiese wird. Die Reihefolge der Attribute repräsetiert die Ragfolge der Sortierug. Die Selektio ermöglicht die Auswahl vo Attribute eier Ressource, wodurch ur die beötigte Iformatioe a de Diestehmer übermittelt werde. Ählich zur Sortierug wird sowohl i [Jau14]) als auch i [Mul12] eie kommaseparierte Liste vorgeschlage, die dem URI-Parameter fields zugewiese wird. Die Pagiierug ermöglicht die Aufteilug vo Iformatioe auf mehrere virtuelle Seite, währed etsprechede Verweise zum Vor- ud Zurückblätter (ext ud prev) sowie zum Sprige a Afag ud Ede (first ud last) existiere. Als URI-Parameter wird offset ud limit empfohle, wobei Ersterer die virtuelle Seite idetifiziert ud Letzterer die Azahl a Iformatioe auf der Seite defiiert. Iteraktio mit Ressource Bei REST agiert ei Diestehmer iemals direkt mit eier Ressource, soder ur über dere Repräsetatioe. Die kokrete Iteraktio erfolgt wiederum mit HTTP- Methode. Die HTTP-Methode sollte ach [Jau14] ud [Mul12] etspreched der gegewärtige HTTP-Spezifikatio (vgl. [RFC2616]) verwedet werde. So sollte beispielsweise die HTTP-Methode GET (kurz: HTTP-GET) ur für seiteeffektfreie ud idempotete Operatioe beutzt werde. Seiteeffektfreiheit bedeutet, dass diese Operatio keierlei Äderuge am Zustad der Ressource vorimmt. Idempotez besagt, dass sich der Zustad durch mehrfaches Ausführe der gleiche Fuktio icht verädert. Tabelle 1 fasst die Eigeschafte für die HTTP-Methode GET, POST, PUT ud DELETE zusamme. Im Hiblick auf Operatioe zum Erstelle, Lese, Modifiziere ud Lösche 01/

5 RESTful Web-Services mit Qualität: Teil 1: Mit Best Practices zu eiem qualitätsorietierte Etwurf HTTP-Methode CRUD-Operatio Beschreibug POST Erstelle (Create) Alege vo eue Iformatioe GET Lese (Read) Abrufe vo Iformatioe PUT Modifiziere (Update) Aktualisiere vo Iformatioe DELETE Lösche (Delete) Lösche vo Iformatioe Tabelle 2: Zuweisug vo CRUD-Operatioe zu HTTP-Methode. (CRUD) vo Iformatioe müsse diese de i Tabelle 1 aufgeführte HTTP-Methode zugewiese werde. Über die Jahre hat sich die i Tabelle 2 dargestellte Zuweisug sowohl i der Praxis als auch i der Literatur etabliert (vgl. [Ric10], [Web10]). Die Uterstützug der HTTP-Methode OPTIONS (kurz: HTTP-OPTIONS) wird empfohle, da die Ressource icht immer alle Operatioe zur Verfügug stelle solle (vgl. [Vi08]). So ka es etwa sei, dass die Literatur & Liks Ressource Nutzer lediglich eie lesede Zugriff erlaubt. Dies führt dazu, dass jegliche Schreiboperatioe ach Beedigug der Übertragug mit eiem etsprechede HTTP-Statuscode beatwortet werde, der ach RFC2616 dem HTTP-Statuscode 405 etspricht. Bei Afrage mit gerige Datemege im Ihaltsbereich vo HTTP stellt dieses Vorgehe kei Problem dar. Dagege muss bei größere Datemege die Verbidug über eie lägere Zeit aufrecht- [Fie00] R.T. Fieldig, Architectural styles ad the desig of etwork-based software architectures, Uiversity of Califoria, Irvie, 2000 [Fie08] R.T. Fieldig, REST APIs must be hypertext-drive, 2008, siehe: [Fie13] R.T. Fieldig, Scrambled Eggs, Evolve 13 The Adobe CQ Commuity Techical Coferece 2013 [Geb11] M. Gebhart, Qualitätsorietierter Etwurf vo Awedugsdieste, KIT Scietific Publishig 2011 [IANA14] IANA, Media Types, 2014, siehe: [If11] IfoQ, How REST replaced SOAP o the Web: What it meas to you, 2011, siehe: [ISO] ISO ud IEC, ISO/IEC 25010:2011 Systems ad software egieerig Systems ad software Quality Requiremets ad Evaluatio (SQuaRE) System ad software quality models [Jau14] S. Jauker, 10 Best Practices for better RESTful API, 2014, siehe: [Mul12] B. Mulloy, Web API Desig Craftig Iterfaces that Developers Love, 2012, siehe: [Pap14] P. Papapetrou, Rest API Best(?) Practices Reloaded, 2014, siehe: [Ric13] L. Richardso, M. Amudse, S. Ruby, RESTful Web APIs, O Reilly & Associates 2013 [RFC2616] IETF, RFC 2616: Hypertext Trasfer Protocol HTTP/1.1, siehe: [RFC6585] IETF, RFC 6585: Additioal HTTP Status Codes, siehe: [Vi08] S. Vioski, RESTful Webservices Developmet Checklist, i: Iteret Computig IEEE Vol. 12 Nr. 6, S , 2008 [Web10] J. Webber, S. Parastatidis, I. Robiso, REST i Practice: Hypermedia ad Systems Architecture, O Reilly Media 2010 erhalte werde, da ei HTTP-Statuscode erst ach Abschluss der Übertragug übermittelt wird. Um dies zu verhider, ka HTTP-OPTIONS verwedet werde, womit erlaubte Methode im Vorfeld abgerufe werde köe. Die Uterstützug vo coditioal GET sollte ach Vioski bei der Etwicklug vo RESTful Web-Services berücksichtigt werde, um uötige Dateverkehr zu verhider. Mit coditioal GET werde bereits empfagee Iformatioe ur bei etwaige Äderuge ereut a de Diestehmer übermittelt. Zu desse Umsetzug existiere zwei verschiedee Asätze (vgl. [Vi08]): Mithilfe der HTTP-Header-Felder Last-modified ud If-modifiedsice. Mithilfe vo so geate etity tags. Uterstützug vo MIME-Type HTTP utzt zur Idetifizierug vo Dateformate so geate MIME-Type (Multipurpose Iteret Mail Extesio), die vo der IANA registriert ud über dere Web- Seite veröffetlicht werde (vgl. [IANA14], [Bi08]). Diese MIME-Type etspreche de Repräsetatiosformate bei REST. Nachfolged kote wir vier Best Practices idetifiziere, die sich dieser Kategorie zuorde lasse: Ei RESTful Web-Service sollte ach [Mul12] midestes zwei verschiedee Repräsetatiosformate uterstütze, zum Beispield JSON oder XML. Als Stadard ist gemäß [Mul12] JSON als Repräsetatiosformat auf Grud steigeder Verbreitug zu wähle. Bei der Wahl der Repräsetatiosformate sollte auf existierede Dateformate aufgesetzt werde, die bereits eie Uterstützug vo Hypermedia biete ud demach für RESTful Web-Services geeiget sid. A dieser Stelle wäre drei populäre JSON-basierte Hypermedia-Formate zu erwähe: JSON-LD, Collectio+JSON ud Sire. Für die Auswahl des MIME-Type sollte HTTP zur Ihaltsvereibarug (Cotet Negotiatio) geutzt werde, mit desse Hilfe der Diestehmer dem Diestgeber über das HTTP- Header-Feld ACCEPT seie akzeptierte Formate mitteilt. Zudem existiert die Möglichkeit, diese Formate etspreched der Präferez des Diestehmers 32

6 mithilfe eies Qualitätsparameters zu gewichte (vgl. [RFC2616], [Vi08]). Fazit I diesem Artikel habe wir Best Practices, die i der Literatur verbreitet sid, i Kategorie zusammegefasst ud mit Qualitätsmerkmale der ISO/IEC 25010:2011 (vgl. [ISO]) verküpft. Durch die steigede Verwedug vo RESTful Web-Services i Projekte hat die Gestaltug der Web-Services zuehmede Eifluss auf die Qualität der gesamte Architektur. Aus diesem Grud müsse auch Web-Services stärker de je mit besoderer Sorgfalt etwickelt werde. Mit userer Übersicht gebe wir Architekte ud Etwickler ei Werkzeug a die Had, um RESTful Web-Services systematisch ud effiziet auf die Eihaltug vo Best Practices utersuche zu köe. Im zweite Teil dieses Artikels werde wir eie Bezug zur ISO/IEC 25010:2011 herstelle, um eie Priorisierug der Best Practices zu ermögliche. Um usere Ergebisse direkt i Projekte awede zu köe, werde wir diese i Form eies Bewertugsboges zusammefasse. Dieser wird zum Dowload bereitstehe ud ka pro Web-Service ausgefüllt werde. User Ziel ist es, hierdurch die Qualität vo Web- Services i Projekte ud somit die Qualität der gesamte Architektur systematisch sicherzustelle. Die Autore Dr. Michael Gebhart (michael.gebhart@iteratec.de) ist IT-Maagemet-Berater bei der iteratec GmbH. Als Berater uterstützt er Kude bei der Kozeptio ud Durchführug vo IT-Projekte sowie der strategische Beratug im EAM- Umfeld. Seie Forschugsschwerpukte sid die Qualitätsaalyse vo Web-Services ud SOAs. Pascal Giessler (pascal.giessler@iteratec.de) ist Software-Igeieur bei der iteratec GmbH i Stuttgart. Nebe dieser Tätigkeit strebt er eie extere Promotio im Bereich der Aalyse vo Softwaresysteme am Karlsruher Istitut für Techologie (KIT) ierhalb der Forschugsgruppe Cooperatio & Maagemet (C&M) a. Prof. Dr. Sebastia Abeck (abeck@kit.edu) leitet a der Fakultät für Iformatik des KIT die Forschugsgruppe Cooperatio & Maagemet (C&M). Seie Forschugsiteresse betreffe die Service-orietierte Architekture, das Iteret der Dige ud das Idetitäts- ud Zugriffsmaagemet. 01/