ist erholsam nur für Webdienste ODER für Webdienste und Webseiten gedacht?

Question

Ich habe viele Restful Tutorials für PHP gelesen.

(Ich will nicht in die Tiefe gehen, warum ich nicht RoR verwendet wird. Es ist aufgrund der Team mit PHP vertraut ist)

Weil wir für die zukünftige Expansion in mit APIs planen i gelesen Es ist wichtig, Restful Web Services zu implementieren.

Ich habe an Tutorials sah wie

http://www.gen-x-design.com/archives/create-a-rest-api-with-php/

Scheinbar ruhig ist für einen Web Service gedacht.

Wie sieht es mit Webseiten aus? können sie auch REST sein?

Wenn die Antwort NEIN ist, gehen Sie bitte nicht über diese Linie hinaus UND sagen Sie es mir einfach. Vielen Dank.

Ich weiß, dass die URLs aussehen wie RESTFUL URLs ist einfach zu verwenden mod_rewrite. Ich bin mir aber ziemlich sicher, dass eine entspannte Architektur nicht nur die URLs gut aussehen lässt.

Für zB habe ich eine Liste von Elementen auf einer Webseite namens list.php. Jeder Artikel verfügt über einen Link zum Löschen. ZB list.php? Id = 1 & DeleteItem

Was passiert, ist, dass, wenn jemand auf der list.php? Id = 1 & DeleteItem Link, ich natürlich gehen zurück auf die gleiche list.php Datei und überprüfen Der Parameter löscht in $ _GET.

Wenn entdeckt, werde ich dann aus der Datenbank basierend auf der Parameter-ID in $ _GET löschen.

Danach werde ich zurück zu list.php ohne params umleiten.

Ich frage mich, wie mache ich diesen ganzen Fluss RESTFULL?

Ich frage, weil in REST, um etwas zu löschen, müssen Sie HTTP-Methode (DELETE) verwenden.

klar in meine Links sind sie alle einfach nur <a href="list.php?id=1&deleteitem">Delete</a>

mich bitte aufklären.

Meine Programmierung ist nicht so stark und es wäre gut, wenn die gegebenen Ratschläge so laienhaft wie möglich sein könnten.

Vielen Dank.

EDIT

Ich habe 2 Fragen folgen zu lassen.

frage 1) Da dies eine Liste von Elementen mit Paging ist, wie würde die URL aussehen, wenn ich es RESTful machen möchte?

Frage 2) Da i Links DELETE neben jedem der Elemente in der Liste bin setzen, verstehe ich jetzt, ich

<form method="POST"> 
<input type=hidden name="_method" value="delete"> 
<input type="submit" > 
</form> 

stattdessen verwenden sollten.

jedoch sollte das Formular an wo gesendet werden? die Artikel-URL?/items/{item-id}

Aber ich möchte zurück zu dieser Liste Seite mit einer Erfolgsmeldung NACH dem erfolgreichen Löschen der Zeile in der Datenbank.

Ich möchte auch eine Popup-Nachricht vermeiden, wenn ich diese Auflistung Seite mit Erfolgsmeldung aktualisieren.

Wenn ich zurück zu dieser list.php URL poste, dann ist es nicht RESTful ja? weil ich durch die Antworten unten gesagt werde, dass jeder Gegenstand eine Quelle ist, die seine eigene URL benötigt.

Bitte erleuchten Sie mich. Vielen Dank.

Answer 1

RESTful wird häufig für Webdienste verwendet, kann aber sehr gut auf Webseiten angewendet werden. Kurz gesagt bedeutet RESTful, mit Ressourcen umzugehen. Eine Ressource kann eine Person, ein Buch, ein Film, ein Theater, ein Ticket oder was auch immer Sie wollen.

Es gibt vier grundlegende Operationen, die Sie an einer Ressource ausführen können.

• erstellen (POST)
• Lesen (GET)
• update (PUT)
• löschen (DELETE)

Die meisten Web-Browser die PUT und DELETE Aktionen nicht unterstützen, so Sie können nur POST-Aktionen zum Senden von Daten verwenden. Rails fälscht PUT und DELETE, indem es einen versteckten Parameter mit dem Namen _method übergibt, den das Framework aufnimmt und abhängig von diesem Wert routet.

Außerdem sollten Sie niemals GET für zerstörende Maßnahmen verwenden. Jede Aktion, die den Status Ihrer Ressource (n) ändert, sollte je nach Änderung entweder mit POST, PUT oder DELETE aufgerufen werden (bei Bedarf Fake PUT/DELETE mit POST).

Ich würde vorschlagen, Sie überprüfen, wie RESTful Routing in Rails behandelt wird, nur um eine Idee zu bekommen, wenn nichts anderes. Obwohl die vier obigen Aktionen ausreichen, um eine Ressource in jeder möglichen Weise zu modifizieren, führt Rails auch drei andere Arten von Aktionen ein, die sich als nützlich erweisen.

• Index (Listungs Ansicht aller Artikel)
• neue
• bearbeiten (in der Regel eine Form im Hinblick auf Updates eine bestehende Ressource)

(in der Regel eine Formularansicht eine neue Ressource hinzufügen)

Beim Entwerfen von RESTful-Sites sind hübsche URLs definitiv auf dem Tisch, aber wahrscheinlich ist der größte Gewinn, dass sich die Codequalität automatisch verbessert. Wenn Sie nur mit Ressourcen arbeiten und es nur vier mögliche Aktionen gibt, die auf eine Ressource angewendet werden können, beginnen die Dinge selbst zu bereinigen.

Edit 1: Selbst beschreibende URLs sind bevorzugt und werden Ihnen das Leben leichter machen, aber es gibt nichts, von der Erstellung kryptischen URLs zu stoppen, die eindeutig eine Ressource identifizieren und verwalten sie die HTTP-Verben verwenden. URLs wie die darunter (mit MD5) zur eindeutigen Identifizierung von Ressourcen sind perfekt RESTful.

// represents a person "John Doe" 
http://example.com/4c2a904bafba06591225113ad17b5cec 

// represents the movie "Lord of the Rings: The Two Towers" 
http://example.com/1d9198260dec7bda3fb21e232d60fec3 

// represents the "Formula One" sport 
http://example.com/fs340as?id=23xa12&type=SP012Ts 

Das ist REpresenational State Transfer genau dort. Der MD5-Hash ist wie die Postanschrift der Ressource, die konstant bleibt. Die Darstellung könnte die Details des Films sein (in html/xml/json/etc.), Oder vielleicht das Video des Films selbst abhängig von den Fähigkeiten des Clients).

Edit 2: Lasst uns sagen, dass Sie eine Ressource, die eine Sammlung - countries der Welt. Es könnte durch ein URI und HTTP-Verb dargestellt werden wie zum Beispiel:

GET /countries 

Da Paging ist eine Eigenschaft der Anwendung anstatt die Ressource selbst, könnten Sie Abfragezeichenfolgeflag Parameter liefern, um es zu kontrollieren.

GET /countries?page=1 

Ein Land ist auch eine Ressource, die ein Teil der Länder Ressource ist.

/countries/<id> 

und Operationen auf diesem Land könnten mit diesen Verben durchgeführt werden: Sie könnten ein Land mit einer URL wie identifizieren

GET /countries/<id> 
POST /countries -- the new country has no existing representation 
PUT /countries/<id> 
DELETE /countries/<id> 

Answer 2

Restful Ansatz kann sicherlich auch in Webseiten verwendet werden. Das Setzen von Befehlen in eine URL ist aufgrund der erwähnten Nebenwirkungen keine gute Idee. Wenn Sie die Datenbank ändern (oder das tun, was das Modell ändert), verwenden Sie POST-Befehle.

Natürlich Sie PUT und delte in gängigen Web-Browsern nicht haben, aber man kann immer eine einfache POST mit einem spezifischen Parameter wie method = "PUT", method = "DELETE" usw.

Answer 3

senden Lange Antwort kurz: Ja. REST ist für beide. Das liegt daran, dass selbst wenn Sie die einfachste aller Websites haben, Sie Ihre Seite trotzdem abholen und eventuell persönliche Daten POST hinzufügen müssen, um einen Eintrag im Gästebuch hinzuzufügen. Da halten wir uns alle irgendwie an REST.

In Ihrem Fall macht eine schlechte Browser-Implementierung es schwierig, eine PURE RESTful-Methode zu implementieren. DELETE wird nicht ohne Javascript unterstützt und daher müssten Sie GET oder POST verwenden (die beide eine völlig andere Bedeutung als DELETE in REST haben).

Answer 4

ich einen kleinen Rahmen auf der Zend Framework geschrieben, um die Umsetzung RESTful Schnittstellen einfacher:

http://github.com/mikekelly/Resauce

können Sie, dass für Web-Services und Websites verwenden. Im Wesentlichen ist eine Website nur ein Webservice, der von HTML gesteuert wird.

Answer 5

RESTful bedeutet nicht "schöne URIs". Trotz der Tatsache, dass URIs eine Ressource identifizieren, ist das einzige, was REST über URIs sagt, dass sie keinen Aktionsparameter wie "delete" enthalten sollten.

In Ihrem Fall würde rufen Sie

DELETE /items/6793 

Die Antwort der Regel Statuscode 200 OK mit der modifizierten Liste als Nachrichtentext wäre.Siehe: http://restpatterns.org/HTTP_Methods/DELETE

Da HTML 4 andere Formularaktionen als GET und POST nicht unterstützt, müssen Sie mit einem versteckten Parameter umgehen und die HTTP-Methode auf der Serverseite überschreiben.