Proste api dla apki

Hej! Zazwyczaj piszę programy i czasem korzystam z jakiegoś API, tym razem jednak muszę stworzyć zarówno API jak i program. Nie jest to dla mnie całkiem obcy temat, ale chciałbym zrobić to lepiej niż zwykle (a zwykle robiłem amatorke, zwracanie liczb rozdzielonych średnikami itd.). Zaczynam od prostego 'chatu' z logowaniem i rejestracją, uznałem, że taki chat jest prosty ale jednocześnie będzie dobra podstawa żeby coś już popracować.

Endpointy w API:

• User/Create - przyjmuje login i hasło, dodaje do bazy nowego użytkownika, zwraca kod błędu/powodzenia
• User/CreateToken - przyjmuje login i hasło, zwraca token
• User/ReleaseToken - 'wylogowanie', wyczyszczenie pola z tokenem
• Chat/Check - zwraca największy messageID
• Chat/Read - zwraca wiadomości z messageID > przeslaneMessageID
• Chat/Send - dodaje do bazy wiadomość*
  z tych plików odnoszę się do innego - database - gdzie mam realizowane połączenie i wklepane dane

Tabele w bazie:

• users - userID, login, pass, token
• messages - messageID, senderID, message

Uwagi:

• Request przyjmuje dane w formie jsona
• Request zwraca dane w formie jsona
• Hasło odkodowuję poprzez base64_encode - dzięki czemu w requeście nie przesyłam żywcem hasła tekstem - wiem, że to żadne zabezpieczenie, no ale zawsze lepiej to wygląda chyba
• Token generowany jest poprzez proste md5(uniqid())
• Mam ładne adresy przez RewriteRule w htaccess
• Przed klepaniem apki testowałem endpointy Postmanem
• Celowo nie korzystam z oauth
• Celowo nie korzystam z frameworków

Pytania:

• Czasem obok tokena wysyłam w requeście userID, żeby wiedzieć kto jest np. autorem wiadomości. Czy lepiej byłoby wydzielić tablicę w bazie dla tokenów, przechowywać tam userID oraz czas ważności tokena, i czyścić je co jakiś czas? Dzięki temu nie musiałbym przekazywać userID obok tokena w np. wysyłaniu czy pobieraniu wiadomości
• Rozdzielenie Check od Read jest celowe, jest to lżejsza operacja, która będzie wykonywana co kilka sekund, dlatego rozdzieliłem sam fakt zmiany od pobierania nowych wiadomości. Wiem, że tutaj websockety albo jakaś inna magia by się pewnie sprawdziła, ale szkoda zachodu chyba
• Czytałem, że api musi być stateless itd, dlatego te CreateToken i ReleaseToken zamiast logowania i wylogowania, ale to takie chyba obchodzenie tematu, nie bardzo wiem co myśleć
• w kilku tutorialach widziałem, że ludzie w php obsługują takie dane wewnątrz requestów obiektowo- ma to sens, nie zabija to wydajności, jak to tylko request na chwilkę?
• w kilku tutorialach widziałem, że ludzie mają jeden plik dostępu do api, i w zależności od metody (get, post, delete)robią dużego ifa/switcha i coś tam działają. Czy to jest lepsze niż to co robię? Szczerze bardziej podoba mi się takie rozwalenie tego na kilka mniejszych plików i endpointów.
• dane do połączenia do bazy - nazwa, login, hasło - zostawić w tym pliczku jednym czy jeszcze jakoś gdzieś wyciągnąć poza?

Generalnie napisałem tego posta, ponieważ chciałbym przy okazji projektu czegoś się podszkolić z tej dziedziny. Nie będzie to api używane do ratowania życia czy obrony narodowej. Jeśli jest coś, co mogę dorobić w dzień dwa, a będzie fajnym rozwiązaniem, to chętnie przygarnę pomysły/linki/uwagi.

Cześć.

1. Wysyłanie User ID osobno nie ma sensu, bo możesz podszywać się pod inne osoby. User ID powinien wynikać z tokena.
2. Ja bym się nie bawił w osobny check, chyba że masz jakiś widok do pokazywania czy są nowe wiadomości, np. ze strony głównej.
3. Prawda jest taka, że cały HTTP jest stateless, więc ciastka też są stateless. Mechanizm ciastek nie różni się aż tak bardzo od tokenów API. Jeśli masz ochotę poćwiczyć zabawę z tokenami lub warstwa klienta i serwera są oddzielone z jakiegoś powodu np. inną domeną, to użyj tokenów. W przeciwnym razie ciastka wystarczą i nie daj sobie wmówić, że używanie ciastek w API to jakaś wiocha. Ciastko też jest swego rodzaju tokenem, tyle że wysyłanym automatycznie.
4. Nie przejmuj się wydajnością obiektówki. Pisz kod tak, żeby był czytelny i łatwy do modyfikacji.
5. Podejście z jednym plikiem to tzw. front controller. Ma to wiele zalet, bo w tym pliku możesz mieć całą logikę "odpalania" Twojego API. Alternatywą jest rozbicie - tak jak mówisz - na pliki i dołączanie w nich wspólnej logiki. Wyjdzie na jedno, ale czyściej jest mieć front controller. Poza tym możesz przecież mieć front controller i nadal rozbijać swoje endpointy na osobne pliki. Tak robi większość frameworków.
6. Teraz jest taki trend, że takie dane jak np. dostęp do bazy trzyma się w specjalnym pliku, który jest w .gitignore. Takim standardem jest plik .env. Dzięki takiej konwencji, programiści nie są uzależnieni od konkretnych danych do bazy, dane te nie zaśmiecają repozytorium, a dodatkowo możesz mieć kilka osobnych baz do testowania i bez problemu sobie je podmieniać, bez obaw że coś pokićkasz w repozytorium.

Polecam pobawić się jakimś małym frameworkiem stworzonym typowo do tworzenia API, np. Lumen. Rozwieje kilka Twoich wątpliwości.

Uzupełniając wpis poprzednika:

Boski napisał(a):

Pytania:

• Czasem obok tokena wysyłam w requeście userID, żeby wiedzieć kto jest np. autorem wiadomości. Czy lepiej byłoby wydzielić tablicę w bazie dla tokenów, przechowywać tam userID oraz czas ważności tokena, i czyścić je co jakiś czas? Dzięki temu nie musiałbym przekazywać userID obok tokena w np. wysyłaniu czy pobieraniu wiadomości

https://en.wikipedia.org/wiki/JSON_Web_Token
Zapisz user ID w tokenie.

• Rozdzielenie Check od Read jest celowe, jest to lżejsza operacja, która będzie wykonywana co kilka sekund, dlatego rozdzieliłem sam fakt zmiany od pobierania nowych wiadomości. Wiem, że tutaj websockety albo jakaś inna magia by się pewnie sprawdziła, ale szkoda zachodu chyba

https://en.wikipedia.org/wiki/Representational_state_transfer
Do jednego użyj HEAD, do drugiego GET.
Ustawiaj pola ETag i/lub Last-Modified.
Zapoznaj się z resztą headerów https://en.wikipedia.org/wiki/List_of_HTTP_header_fields

• Czytałem, że api musi być stateless itd, dlatego te CreateToken i ReleaseToken zamiast logowania i wylogowania, ale to takie chyba obchodzenie tematu, nie bardzo wiem co myśleć
• w kilku tutorialach widziałem, że ludzie w php obsługują takie dane wewnątrz requestów obiektowo- ma to sens, nie zabija to wydajności, jak to tylko request na chwilkę?

Normalnie też masz tylko request na chwilkę. Różnica site vs api to session vs stateless. W tej różnicy głównie chodzi o możliwość/brak możliwości używania request cache pomiędzy api a twoją aplikacją. Zaczyna mieć znaczenie przy dużym ruchu.

Dziękuję bardzo za odpowiedzi, będę googlać i czytać. Dwa pytanka:

• czyli tak przygotowanego tokena nie muszę przechowywać w bazie? Tylko dekodowa ID użytkownika i dane przy zapytaniu
• fron controller - a jeśli mam kilka operacji na get (pobieranie usera, wiadomosci, innych danych) lub post (tworzenie usera, tworzenie wiadomosci), to muszę przesłać dodatkowo coś co zawiera info czego dotyczy request?

Boski napisał(a):

• czyli tak przygotowanego tokena nie muszę przechowywać w bazie? Tylko dekodowa ID użytkownika i dane przy zapytaniu

Tylko do uwierzytelniania - nie musisz. Przechowywać coś musisz gdy chcesz unieważnić tokeny (dodatkowo, przed czasem ich wygaśnięcia).

• fron controller - a jeśli mam kilka operacji na get (pobieranie usera, wiadomosci, innych danych) lub post (tworzenie usera, tworzenie wiadomosci), to muszę przesłać dodatkowo coś co zawiera info czego dotyczy request?

Opisałeś kilka endpointów:
/user, /users, /messages, /otherdata.