REST Fundamentals

Editor's Notes

• #3: KönntihreucheinLebenohne die unglaublicheMenge an Informationenim Web nochvorstellen?
• #4: Ichnicht!
• #5: WennichmeinVerhaltenanschaue:Lese RSS Feeds, BucheZugticketsüber Browser oder AppDas Web verändertewiewirInformationenproduzierenoderkonsumierendramatisch
• #6: Was macht das Web eineerfolgreicheApplikationsplattform?Architekturnichtsweiteresalstausende von einfachenInteraktionenzwischenAgenten und RessourcenNutzen HTTP und URI alsTechnologie
• #7: SchlüsselkonzeptoderFundamentalerBausteinFast alleskannalsRessourcemodeliertwerdenWirdzur Manipulation zurVerfügunggestelltRessource != Datenbankentität
• #8: Für die Manipulation brauchtes Resource Identifiers (URI = Uniform Resource Identifier)EindeutigadressierbarURIs und Ressourcen = Many to OneMehrere URIs pro Ressource (http://..., file://...)
• #9: MetadatenInformationenüberAufenthaltsort, Alternative Formate, Alter, oderEntitätsinformationenWichtigerAspektfürSkalierbarkeithierzufinden = CachingErlaubtKopien an mehrerenOrtenzuspeichern (auf Request-Response Pfad)
• #10: Metadatenbrauchen Caching Direktivenwie Expires, Cache-Control, Etagoder Last-ModifiedVeralteteRessourcenmüssenrevalidiertwerdenvomOriginserverKonditional Requests!Etagmit If-Match und If-None-Match oder Last-Modified mit If-Unmodified-Since oder If-Modified-SinceBody nurgesandt falls nötig
• #11: XML, JSON, Image odermehrRessourcezueinemPunkt in der ZeitContent-Negotiation ProzesshandeltzurLaufzeit die RepräsentationausDochwieInteragieren?
• #12: GET, POST, PUT, DELETE, OPTIONS, HEAD, TRACE, CONNECT und PATCHDemos zeigenBedeutungResponse Codes 200 OK, 201 Created, 404 Not FoundDefinierenGenerisches Framework fürInteraktion
• #13: Schauenwir das Ganze in einer Demo anBACK: GutesBeispielfürverteilteArchitektur, Skaliert gut mitaddressierbarenRessourcen, Repräsentationen und KommunikationsmittelnEinfacheSchnittstellezukomplexenApplikationenInformation Hiding (Abstrahiertkonkrete Dinge wie DB etc.) hinter einemeinzigenKonzept
• #14: DIE RESSOURCEUnd bisjetzthabenwirnochnichtüber REST gesprochensondernnurüber die Webarchitektur
• #15: Representational State TransferRoy Fielding’s DissertationAnalysierte die Erfolgsgeschichte des WebsReihe von Einschränkungen auf eigeneArchitekturanwenden ProfitKurz: Reihe von Einschränkungen, darumArchitekturstil
• #16: Befolgt man alleEinschränkungen = RESTfulWeitererAspekt der Hochverfügbarkeit?
• #17: Hypermediaoder Hypermedia as the engine of application state (HAT OASE = HATEOAS)Einfachaber genialApplikationbewegtsichvorwärts von einemZustandzumAnderenwieStatemachineZuständenichtvorherbekannt, müssenentdecktwerdenRichtigangewendet = Web-friendly, wiemessen?
• #18: Leonard Richardson KlassifikationsmodellMaturitätslevelfürApplikationen und ServicesAuf Basis: URIs, HTTP und Hypermedia
• #19: Level Null, einzige URI nur POST VerbPlain Old XmlPOST http://localhost/api newAccount { }POST http://localhost/api updateInvoice { }
• #20: Level Eins,Operationsnamen und Parameter in der URIHat zwarmehrereRessourcen (Teile und Herrsche)Benutztnur GETGET http://localhost/api/account?=newGET http://localhost/api/invoice?=update
• #21: Level Zwei, URI addressierbareRessourcen,abernur CRUD (GET, POST, PUT und DELETE)FührtStandardset von Verbenein, reduziert die Anzahl an VariationenKeineEntdeckbarkeit
• #22: Das meiste Web-friendlyLeve!EinzigesRESTfulEntdeckbar und Selbstdokumentierend
• #23: Was fürein Level ist das?
• #24: Startenwir in die DemoBACK: KlaresVerständnisfür REST, Prinzipien des SkalierbarenVebs auf deineSoftwarearchitekturangewendet
• #25: Nochnichtüberzeugt? Willst du lernenwieRessourcendefinieren,Transitionen, Versionierung? Kein Problem! Vote fürnächstenVortrag