Ich suche nach einer Möglichkeit, APIs um Standardfunktionen in meinen PHP-basierten Webanwendungen, Datenbanken und CMS zu wickeln.

Ich habe mich umgesehen und mehrere "Skeleton" Frameworks gefunden. Zusätzlich zu den Antworten in meiner Frage gibt esTonic, ein REST-Framework, das ich mag, weil es sehr leicht ist.

Ich mag REST wegen seiner Einfachheit am liebsten und würde gerne eine API-Architektur darauf aufbauen. Ich versuche, mich mit den Grundprinzipien vertraut zu machen und habe sie noch nicht vollständig verstanden. Daher eine Reihe von Fragen.

1. Verstehe ich es richtig?

Angenommen, ich habe eine Ressource "Benutzer". Ich könnte eine Reihe von URIs wie folgt einrichten:

/api/users     when called with GET, lists users
/api/users     when called with POST, creates user record
/api/users/1   when called with GET, shows user record
               when called with PUT, updates user record
               when called with DELETE, deletes user record

Ist dies eine korrekte Darstellung einer RESTful-Architektur?

2. Ich brauche mehr Verben

Erstellen, Aktualisieren und Löschen mögen theoretisch ausreichen, aber in der Praxis werde ich viel mehr Verben benötigen. Mir ist klar, dass dies Dinge sind, diekönnte in eine Aktualisierungsanforderung eingebettet sein, aber es handelt sich um bestimmte Aktionen, die bestimmte Rückkehrcodes haben können, und ich möchte sie nicht alle in einer Aktion ausführen.

Einige, die im Benutzerbeispiel in den Sinn kommen, sind:

activate_login
deactivate_login
change_password
add_credit

Wie würde ich Aktionen wie die in einer RESTful-URL-Architektur ausdrücken?

Mein Instinkt wäre ein GET-Aufruf an eine URL wie

/api/users/1/activate_login 

und erwarte einen Statuscode zurück.

Das weicht jedoch von der Idee ab, HTTP-Verben zu verwenden. Was denkst du?

3. Zurückgeben von Fehlermeldungen und Codes

Ein großer Teil der Schönheit von REST beruht auf der Verwendung von Standard-HTTP-Methoden. Bei einem Fehler sende ich einen Header mit einem 3xx-, 4xx- oder 5xx-Fehlerstatuscode aus. Für eine detaillierte Fehlerbeschreibung kann ich den Body verwenden (oder?). So weit, ist es gut. Aber was wäre der Weg, um aproprietärer Fehlercode das ist detaillierter beschrieben, was schief gelaufen ist (z. B. "Verbindung zur Datenbank fehlgeschlagen" oder "Datenbankanmeldung falsch")? Wenn ich es zusammen mit der Nachricht in den Körper lege, muss ich es anschließend auswerten. Gibt es einen Standardheader für solche Dinge?

4. So führen Sie die Authentifizierung durch

Wie würde eine auf API-Schlüsseln basierende Authentifizierung nach REST-Prinzipien aussehen?Gibt es starke Argumente gegen die Verwendung von Sitzungen bei der Authentifizierung eines REST-Clients, abgesehen davon, dass dies eine offensichtliche Verletzung des REST-Prinzips darstellt? :) (nur ein Scherz hier, würde sitzungsbasierte Authentifizierung gut mit meiner vorhandenen Infrastruktur spielen.)