Erstellen Sie eine RESTful API in PHP?

Wenn Ihr Service alle CRUD-Operationen unterstützt, ist es immer ratsam, eine REST-konforme Schnittstelle zu implementieren. Es ist nicht besonders schwer, das zu tun. Ich habe einige der folgenden Grundlagen erläutert.

Ein RESTful Service macht einfach ein paar Dinge:

1. Es verwendet die HTTP-Anfrage-Methode für die Kommunikation der CRUD-Aktion
2. Es verwendet HTTP-Statuscode, um den Antwortstatus zu kommunizieren, und
3. Er verwendet den URI, um Ihre Ressource zu definieren (Datei, Datenbankelement, auf das Sie zugreifen, usw.).
4. Es ist staatenlos

Die Idee besteht darin, die Entwicklung von benutzerdefinierten Kommunikationen für diese Dinge zu minimieren, die bereits in der HTTP-Spezifikation definiert sind.

1 - ANFRAGE METHODE

Die vier HTTP-Request-Methoden, die Sie für einen RESTful-Service unterstützen müssen, sind:

1. POST
2. GET
3. PUT
4. LÖSCHEN

und Sie können optional

1. PATCH
2. KOPF

Sie können diese wie folgt direkt Ihren CRUD-Aktionen zuordnen:

• POST = Erstellen
• GET = Abrufen
• PUT = Aktualisieren
• DELETE = Löschen
• PATCH = Edit (ein teilweises Update, z. B. "change password". PUT wird zu "replace")
• HEAD = Nur Kopfzeile (Metadaten über die Ressource)

Um dies zu tun, leiten Sie Anfragen mit einem einfachen Request-Methoden-Router wie folgt richtig:

2 - STATUSCODE Sie sollten außerdem HTTP-Statuscodes von Ihrem Dienst implementieren, um den Status zurück an den Client zu übermitteln, z. B .:

• 20x = Erfolg
• 30x = Umleitung
• 40x = Kommunikationsprobleme
• 50x = Serverfehler

Geben Sie dazu einfach Ihre Antwort mit der richtigen HTTP-Header-Ausgabe an, z. B .:

Sie können hier auf die vollständige Liste der implementierten HTTP-Statuscodes verweisen: Ссылка

3 - URIs Bei URIs folgen REST-konforme Dienste normalerweise einem Top-down-Ansatz für die kategorisierte Benennung, z. B.

Beispiele:

Sie können einen sehr rudimentären RESTful-Router für die obige Konvention implementieren, indem Sie Apache mit mod_rewrite in einer .htaccess -Datei wie folgt verwenden:

Sie hätten dann index.php Suchen Sie nach dem entsprechenden Objekttyp und der entsprechenden ID, um entsprechend zu routen, z. B .:

4 - STATELESSIGKEIT Einfach gesagt, der Server behält keinen "Status" für den Client bei. Keine Anforderungen zum Speichern der Sitzung oder des Status. Jede Anfrage repräsentiert eine vollständige Transaktion. I.e. Wenn ich den Benutzer / 1 abhole, erinnert sich der Server nicht daran, dass ich das getan habe, und zukünftige Anforderungen hängen nicht von vorherigen ab oder werden von diesen beeinflusst.

Wenn Sie diese Standards implementieren, herzlichen Glückwunsch, Sie haben einen RESTful Service erstellt!

"RESTful" ist ein weitgefasster Begriff und es gibt Grade von "RESTfulness". Wikipedia ist eine gute Anleitung hier

Hier sind einige Eigenschaften höherer Ebene, die in der anderen Antwort nicht angesprochen werden (was auch gut ist):

1. Ressourcen sind unter URLs verfügbar, vorzugsweise mit nur einer kanonischen URL pro Ressource.
   • Sie können angeben, dass eine Ressource in anderen URLs oder Darstellungen verfügbar ist, indem Sie den Header Content-Location verwenden.
   • Sie können verschiedene Darstellungen einer Ressource (html, json, xml usw.) bereitstellen, indem Sie die Inhaltsverhandlung mit den Kopfzeilen Accept und content-type verwenden.
2. Änderungen im Status der Ressource werden vollständig durch eine einzelne HTTP-Anfrage dargestellt. Der Server muss den Status zum Bedienen einer Clientanforderung nicht beibehalten. Folglich können Anforderungen leicht proxiiert und zwischengespeichert werden.
   • Ein Beispiel für eine häufige Verletzung dieses Prinzips ist eine URL wie "http://example.org/profile", die je nachdem, wer eingeloggt ist, ein anderes Benutzerprofil verwendet.
   • Besser wäre es, die Ressource von der Autorisierung zu trennen: "http://example.org/profile/{USERID}" würde immer die Benutzer-ID eines bestimmten Benutzers liefern, aber 401 (Nicht autorisiert) zurückgeben, wenn der Client keine Berechtigung hat . (Außerdem sollten Autorisierungsinformationen bei jeder Anforderung gesendet werden, sodass der Server kein Sitzungstoken oder einen ähnlichen serverseitigen Status benötigt. Daher sind die meisten Websites mit einem Cookie-basierten Anmeldesystem nicht rein erholsam.)
   • GET, um eine Ressource abzurufen. Dies sollte den Status der Ressource nicht ändern und sollte sicher wiederholbar sein. Diese Eigenschaft wird oft als "Idempotenz" bezeichnet.
   • PUT, um eine Ressource zu aktualisieren. Mit Techniken wie bedingten Aktualisierungsanforderungen (PUT oder DELETE mit einem if-* Header) können Sie sogar optimistisch implementieren Gleichzeitigkeitskontrolle.
   • LÖSCHEN, um eine Ressource zu entfernen.
   • POST als Catchall "tue etwas" -Ressource. POST wird verwendet, wenn Sie etwas tun müssen, das nicht sauber in die HTTP-Methoden passt oder wenn Sie eine Aktion mit Nebeneffekten ausführen müssen (z. B. eine neue Ressource erstellen, ohne den Namen zu kennen oder ein RPC-Protokoll zu implementieren). Es wird jedoch erwartet, dass Sie HTTP-Header und Response-Codes verwenden, um zu zeigen, welche Ressourcen-Nebenwirkungen dort waren, z a "201 Created" mit den Headers Location und Content-Location und einer Liste der von der Änderung betroffenen URLs.
3. Ressourcendarstellungen sind selbstbeschreibender "Hypertext" mit Links zu anderen Ressourcen.
   • Ein Beispiel für eine Verletzung dieses Prinzips: Angenommen, "http://example.com/articles" ist eine Liste von Artikeln und die JSON-Darstellung davon sieht wie [1,2,3,4,5,6] aus. Dies ist eine Liste von Artikel-IDs, aber es ist nicht selbstbeschreibend oder Hypertext - der Client muss wissen, dass dies eine Liste von Artikel-IDs ist, und es muss wissen, um eine Artikelressource zu erhalten, muss es eine URL wie erstellen http://example.org/articles/1 ".
   • Besser wäre eine Antwort wie {"articles":[{"id":1,"url":"http://example.org/articles/1"},...]} . Wie html sollte ein Client, der einen Restdienst verwendet, nur folgen -Links (nicht make -Links) haben, um andere verwandte Ressourcen zu erhalten. Sie können sogar die verfügbaren Methoden dokumentieren, mit denen Sie eine Ressource manipulieren können: Erstellen, Aktualisieren, Löschen usw.