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 Abb. 2: Keie Vermischug des Numerus bei der Bezeichug der Ressource. stelle wir im erste Teil dieses zweiteilige Artikels eie Mege a Best Practices vor, die für de Etwurf vo RESTful Web-Services relevat sid ud dere Qualität beeiflusse (Herausforderug 1). Die Best Practices stamme dabei aus besteheder Literatur ud vereiheitliche diese. Um eie Priorisierug der Best Practices zu ermögliche (Herausforderug 2), werde wir im zweite Teil des Artikels die Best Practices mit Qualitätsmerkmale wie Wartbarkeit ud Effiziez aus der ISO/IEC 25010:2011 (vgl. [ISO]) verküpfe. Zusätzlich werde wir zeige, wie auf Basis der Ergebisse vo Michael Gebhart (vgl. [Geb11]) eie Automatisierug durch Werkzeuge erfolge ka. Um die Ergebisse i Projekte eizusetze, stelle wir im zweite Teil eie Bewertugsboge zum Dowload bereit, mit dem RESTful Web-Services i Projekte systematisch geprüft werde köe. Best Practices für REST Für REST gibt es eie Vielzahl a uterschiedliche Best Practices, die wir achfolged beleuchte wolle. Wir gruppiere hierzu die gesammelte Best Practices i acht verschiedee Kategorie ud setze die Nutzug des Awedugsprotokolls Hypertext Trasport Protocol (HTTP) (vgl. [RFC2616]) für die achfolgede Betrachtug voraus. Versioierug Eie Versioierug ist gemäß Bria Mulloy (vgl. [Mul12]) eie der wichtigste Betrachtuge beim Etwurf eies Web-Service, weshalb desse Schittstelle (achfolged als Web-API bezeichet) iemals ohe eie Versioserkeug veröffetlicht werde sollte. Dem gegeüber steht die Aussage vo Fieldig: Versioig a iterface is just a polite way to kill deployed applicatios (vgl. [Fie13]). Durch das Prizip vo Hypermedia As The Egie Of Applicatio State (HATEOAS) ka ei RESTful Web- Service mit eier herkömmliche Web-Seite vergliche werde, wodurch eie Versioierug obsolet wird. Dies setzt atürlich voraus, dass HATEOAS sowohl bei der Etwicklug des Web-Service als auch bei desse Diestehmer berücksichtigt wird. Beschreibug vo Ressource Die Beschreibug vo Ressource ist für die Beutzbarkeit eies Web-Service etscheided, da die Ressource die Domäe abbilde. Hierfür kote wir folgede sechs Best Practices idetifiziere: Für die Bezeichug vo Ressource sollte Nome verwedet werde, da dies eie etablierte Kovetio darstellt (vgl. [Mul12], [Vi08], [Pa14]). Die Ressource sollte domäespezifisch ud kokret beat sei, sodass dere Bedeutug abgeleitet werde ka (vgl. [Jau14], [Pa14]). Die Azahl der Ressource sollte zwische 12 ud 24 liege, um so die Komplexität des Systems zu begreze (vgl. [Mul12]). Dadurch muss uter Umstäde ei Kompromiss zwische der Bezeichug der Ressource ud dere Azahl eigegage werde. Auf die Vermischug des Numerus bei der Bezeichug vo Ressource sollte verzichtet werde, währed gleichzeitig eie Präferez für die Pluralform ausgesproche wird (siehe Abbildug 2). Vergleichbar mit Klasse bei der Objektorietierug köe auch Ressource Attribute ethalte. Für dere Bezeichug sollte die Biemajuskeloder auch Kamelhöcker-Schreibweise mit führedem Kleibuchstabe verwedet werde, welche sich auch i der Programmierug etabliert hat (vgl. [Mul12]). Da der Medietyp JavaScript Object Notatio (JSON) immer häufiger bei der Iteraktio mit Web-Services eigesetzt wird, sollte bei der Bezeichug der Attribute die Nameskovetioe vo JavaScript beachtet werde (vgl. [Mul12]). Idetifizierug vo Ressource Die Idetifizierug vo Ressource erfolgt gemäß Fieldig (vgl. [Fie00]) mithilfe eies Uiform Resource Idetifier (URI). Hierfür kote wir die folgede vier Best Practices idetifiziere: Die URI sollte gemäß der Affordaz selbsterkläred sei (vgl. [Mul12]). 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 A- 01/

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. sammlug 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] 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. 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. 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 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: 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. 30

4 HTTP-Methode Seiteeffektfreiheit Idempotet POST Nei Nei GET Ja Ja PUT Nei Ja DELETE Nei Ja Tabelle 1: Eigeschafte der häufigste HTTP-Methode. 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. Abb. 3: Abstraktes Ressourcemodell. 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 gewü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 (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 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. Da- 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. gege muss bei größere Datemege die Verbidug über eie lägere Zeit aufrechterhalte 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 Literatur & Liks 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. [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 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 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 systema- 32

6 tisch 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 Prof. Dr. Sebastia Abeck (abeck@kit.edu) leitet a der Fakultät für Iformatik des Karlsruher Istituts für Techologie (KIT) die Forschugsgruppe Cooperatio & Maagemet (C&M). Seie Forschugsiteresse betreffe SOAs, das Iteret der Dige sowie Idetitätsud Zugriffsmaagemet. Dr. Michael Gebhart (michael.gebhart@iteratec.de) ist IT-Maagemet-Berater bei der iteratec GmbH. Er uterstützt 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@studet.kit.edu) ist Masterstudet am KIT i der Forschugsgruppe Cooperatio & Maagemet. Zuvor begleitete er ei Forschugsprojekt für modellgetriebee Softwareetwicklug i der Forschugsgruppe Software Desig & Quality (SDQ). 01/