Szukam sposobu na zawijanie interfejsów API wokół domyślnych funkcji w aplikacjach internetowych, bazach danych i systemach CMS opartych na PHP.

Rozejrzałem się i znalazłem kilka szkieletów. Oprócz odpowiedzi w moim pytaniu jestTonik, REST, który lubię, ponieważ jest bardzo lekki.

Lubię REST, najlepiej ze względu na jego prostotę i chciałbym stworzyć architekturę API opartą na nim. Próbuję obalić podstawowe zasady i jeszcze nie do końca to zrozumiałem. Dlatego też wiele pytań.

1. Czy rozumiem to dobrze?

Powiedz, że mam zasób „użytkownicy”. Mógłbym skonfigurować wiele takich identyfikatorów URI:

/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

czy jest to poprawna reprezentacja architektury RESTful?

2. Potrzebuję więcej czasowników

Stworzenie, aktualizacja i usunięcie może być wystarczające w teorii, ale w praktyce będę potrzebował dużo więcej czasowników. Zdaję sobie sprawę, że to są rzeczymógłby być osadzone w żądaniu aktualizacji, ale są to konkretne działania, które mogą mieć określone kody powrotu, a ja nie chciałbym ich wszystkich w jednym działaniu.

Niektóre z nich, które przychodzą na myśl w przykładzie użytkownika, to:

activate_login
deactivate_login
change_password
add_credit

jak wyraziłbym działania takie jak te w architekturze URL RESTful?

Moim instynktem byłoby wykonanie wywołania GET na adres URL

/api/users/1/activate_login 

i oczekuj, że kod statusu zostanie przywrócony.

To jednak odbiega od idei używania czasowników HTTP. Co myślisz?

3. Jak zwracać komunikaty o błędach i kody

Duża część piękna REST wynika z użycia standardowych metod HTTP. W przypadku błędu wysyłam nagłówek z kodem statusu błędu 3xx, 4xx lub 5xx. Aby uzyskać szczegółowy opis błędu, mogę użyć ciała (prawda?). Jak na razie dobrze. Ale jaki byłby sposób przekazywaniazastrzeżony kod błędu który jest bardziej szczegółowy w opisie tego, co poszło źle (np. „nie udało się połączyć z bazą danych” lub „błędne logowanie do bazy danych”)? Jeśli włożę go do ciała wraz z wiadomością, muszę go później przeanalizować. Czy istnieje standardowy nagłówek dla tego rodzaju rzeczy?

4. Jak przeprowadzić uwierzytelnianie

Jak wyglądałoby uwierzytelnianie oparte na kluczu API według zasad REST?Czy istnieją mocne punkty przeciwko używaniu sesji podczas uwierzytelniania klienta REST, poza tym, że jest to rażące naruszenie zasady REST? :) (tylko na wpół żartuję, uwierzytelnianie oparte na sesji dobrze by pasowało do mojej istniejącej infrastruktury)