Nun, es gibt viele Möglichkeiten zu lernen, wie man eine RESTful-Webanwendung erstellt, und nein, es gibt keinen eindeutigen richtigen Weg. RESTful ist kein Standard, sondern verwendet eine Reihe von Standards (HTTP, URI, Mime Type, ...).
Beginnen Sie damit: Wie ich REST meiner Frau erklärt habe
Fahren Sie dann wie folgt fort : RESTful Web Services Cookbook
Und dann gib deine ganze Anstrengung auf die Entwicklung von Webanwendungen, denn der beste Weg zu lernen sind Experimente, und du kannst so viel aus deinen Fehlern lernen;)
Machen Sie sich keine Sorgen, wenn Ihre ersten Web-Apps nicht vollständig RUHIG sind: Sie werden den Weg dazu finden!
Zitat von Obi-Wan Kenobi: "Möge die Macht mit dir sein!" ;)
BEARBEITEN
Ok, lassen Sie mich genauer sein.
Du willst eine RESTful Webapp machen, was? Nun, wie gesagt, es gibt viele Möglichkeiten, dies zu tun, aber dies ist die Hauptrichtlinie.
Definition
REST (Representational State Transfer) ist ein Softwarearchitekturstil für verteilte Systeme (wie WWW). Es handelt sich nicht um einen Standard, sondern um eine Reihe von Standards: HTTP, AJAX, HTML, URI, Mime-Typ usw. Es handelt sich um die Darstellung einer Ressource, nicht um eine Ressource selbst. Aus 'Wie ich meiner Frau REST erklärt habe':
Frau : Eine Webseite ist eine Ressource?
Ryan : Irgendwie. Eine Webseite ist eine Darstellung einer Ressource. Ressourcen sind nur Konzepte.
Einschränkungen der Architektur
- Client-Server : Client und Server werden durch die Uniform Interface (nachfolgend beschrieben) getrennt.
- Statuslos : Die Server-Client-Kommunikation wird ausgeführt, ohne dass ein bestimmter Client-Status auf dem Server gespeichert wird.
- Cachable : Der Client verfügt möglicherweise über einen Cache mit Antworten auf bereits erfolgte Anforderungen.
- Layered System : Der Client weiß nicht, ob er direkt mit einem End-Server verbunden ist oder ob die Kommunikation über Zwischenprodukte erfolgt.
Einheitliche Schnittstelle
- Identifikation der Ressourcen: Jede Ressource muss durch einen URI identifiziert werden.
- Protokoll : Um in die Kommunikation zwischen Client und Server zu gelangen, muss zuvor ein Protokoll erstellt werden. Jede Anforderung verfügt möglicherweise über den richtigen MIME-Typ (application / xml, text / html, application / rdf + xml usw.), die richtigen Header und die richtige HTTP-Methode (siehe CRUD-Beschreibung unten).
CRUD
Ok, wir haben gesehen, dass wir URIs verwenden können, um Ressourcen zu identifizieren, aber wir brauchen noch etwas anderes für die Aktionen (Hinzufügen, Ändern, Löschen usw.): Herzlich willkommen bei CRUD (Erstellen, Lesen, Aktualisieren und Löschen).
- Erstelle { HTTP: POST } { SQL: INSERT } => erstelle eine neue Ressource
- Lesen Sie { HTTP: GET } { SQL: SELECT } => eine Ressource abrufen
- Aktualisiere { HTTP: PUT } { SQL: UPDATE } => ändere eine Ressource
- Löschen Sie { HTTP: DELETE } { SQL: DELETE } => eine Ressource löschen
In Bezug auf PUT und DELETE können nun einige technische Probleme auftreten (Sie erhalten diese mit HTML-Formular): Entwickler umgehen dieses Problem häufig, indem sie POST für jede 'PUT'- und' DELETE'-Anforderung verwenden. Offiziell müssen Sie PUT und DELETE verwenden. Übrigens, mach was du willst. Meine Erfahrung zwingt mich, jedes Mal POST und GET zu verwenden.
--- Der nächste Teil sollte verwendet werden, aber es handelt sich nicht um eine REST-Bindung: Es handelt sich um verknüpfte Daten ---
URI
Abstrakte URI aus technischen Details! Verabschieden Sie sich wie folgt von URI:
http://www.example.com/index.php?query=search&id=9823&date=08272012
URI neu gestalten! Nehmen Sie den obigen Link und ändern Sie ihn wie folgt:
http://www.example.com/search/2012/08/27/9823
Das ist viel besser, oder? Dies könnte geschehen durch:
Eine andere Sache: Verwenden Sie unterschiedliche URIs, um unterschiedliche Ressourcen darzustellen:
Achtung : about.html und about.rdf sind keine Dateien! Sie könnten das Ergebnis einer XSLT-Transformation sein!
Inhaltsverhandlung
Wenn Sie diesen Punkt erreicht haben, herzlichen Glückwunsch! Wahrscheinlich sind Sie bereit, abstraktere Konzepte zu erhalten, da wir die technischen Details des Semantic Web eingeben.
GET http://www.example.com/about
Accept: application/rdf+xml
Der Server antwortet jedoch nicht mit "about.rdf", da er einen anderen URI hat ( http://www.example.com/about.rdf ). Schauen wir uns also das 303-Muster an ! Server wird dies zurückgeben:
303 See Other
Location: http://www.example.com/about.rdf
Der Client folgt dem zurückgegebenen Link wie folgt:
GET http://www.example.com/about.rdf
Accept: application/rdf+xml
Schließlich gibt der Server die angeforderte Ressource zurück:
200 OK
about.rdf
Keine Sorge: Ihre Client-Anwendung macht nichts davon! Das 303-Muster muss von der Serveranwendung erstellt werden, den Rest erledigt Ihr Browser.
Fazit
Oft ist die Theorie weit von der Praxis entfernt. Ja, jetzt wissen Sie, wie Sie eine RESTful-Anwendung entwerfen und entwickeln, aber die obige Richtlinie ist nur ein Hinweis. Sie werden Ihren besten Weg finden, um Webanwendungen zu erstellen, und wahrscheinlich wird es nicht so sein, wie es die Theorie will. Mach dir keine Sorgen: D!
Literaturverzeichnis
RESTful Web Services, Sameer Tyagi
REST-APIs müssen hypertextgesteuert sein, Roy Thomas Fielding
RESTful Web Services: Die Grundlagen, Alex Rodriguez
Webber REST Workflow