Witam

Uczę się już od jakiegoś czasu PHP, myślę, że znam je całkiem nieźle i stwierdziłem, że nadeszła pora poznać jakiś framework. Mój wybór padł na Slim, ponieważ wydaje się dość mały i nietrudny do zrozumienia. Zacząłem już trochę go poznawać.
Jednocześnie też zacząłem tworzyć sobie mały projekt, który będzie składał się ze strony www i w przyszłości pewnie też aplikacji mobilnych (taki jest plan na daleką przyszłość, jeśli wszystko by wypaliło) - ma to służyć i nauce frameworka i zrobieniu czegoś fajnego. Całość ma być dość mała, żadne rozbudowane rzeczy. Pomyślałem więc, że tutaj dobrym rozwiązaniem będzie zrobienie jakiegoś API, dzięki któremu i strona i aplikacje mobilne będą mogły komunikować się z serwerem. Nie wiem jednak do końca jak zrobić, aby to wszystko miało sens i trzymało się jakiś zasad - to znaczy mam jakiś ogólny pogląd na to, ale nie za bardzo poukładany. Przychodzę więc z kilkoma pytaniami.

1. Czy taki pomysł robienia aplikacji tego typu jest dobry? Czy stworzenie takiego API jest dobrym pomysłem? Jak połączyć stronę (która jak rozumiem musi być osobną aplikacją) z takim API, słyszałem kiedyś o czymś takim jak klient Guzzle, czy to by się nadało?
2. Czy framework Slim będzie w porządku? Tak, wiem, że są różne i nie da się określić, który to jest dobry a który zły, ale pytam tak ogólnie, czy Slim nadaje się do zrobienia API i jest wart uwagi i nauki? Aplikacja będzie mała, więc chyba ładowanie niczego wielkiego nie ma sensu.
3. Czego z frameworka Slim używać do łączenia się z bazą danych? Po prostu zwykłe PDO? Jakiś ORM? Na stronie Slima pokazany jest Eloquent, słyszałem też dużo dobrego o Doctrine, nie wiem co warto wybrać. Przypomnę też, że ma to być dość mały projekt. Baza z jakiej korzystam to MySQL, ewentualnie zastanawiam się nad PostgreSQL.
4. Chciałbym, aby skorzystać z takiego API mogły tylko moje aplikacje, nie chciałbym tak aby każdy mógł napisać swoją wersję aplikacji i podpinać pod moje API, czy jest taka możliwość? Słyszałem coś o OAuth, w praktyce jednak nie wiem czy jego użycie ma sens, czy zabezpieczy mnie przed tym i jak dokładnie go użyć.
5. Może macie jakieś ogólne wskazówki na temat przygotowywania takiego API? Każda mi się przyda, to będzie pierwsze API jakie będę tworzył (no ale jakoś trzeba przecież zacząć)

Z góry dziękuję za każdą pomoc, jest to dla mnie bardzo ważne.
Pozdrawiam, Marek

1. Tak, to jest dobry pomysł, choć nie jestem pewien czy od tego bym zaczynał. Możesz w ten sposób pominąć etap zrozumienia jakie zalety ma oddzielenie API. Jest to jednak właściwy kierunek tworzenia aplikacji internetowych moim zdaniem. Warto zrozumieć jak działa HTTP, wtedy wszystko zaczyna się układać w całość. Klient Guzzle, i jemu podobne, po prostu wysyłają zapytania HTTP i otrzymują odpowiedzi. Możesz dzięki temu czytać zewnętrzne API.
2. Tak, framework Slim jest w porządku.
3. ORM bardzo ułatwia korzystanie z bazy danych, Twój kod będzie ładniejszy. PDO to podejście o niższym poziomie abstrakcji. Też zadziała, ale będzie mniej elastyczne i bardziej upierdliwe. Osobiście używam głównie Eloquenta i sobie chwalę.
4. Oczywiście, jest taka możliwość. Nie jest to jednak temat do przedstawienia w dwóch zdaniach. Mówiąc krótko: musisz zabezpieczyć swoje API przez niepowołanym dostępem. Jeśli jest jakikolwiek sposób na odczytanie co znajduje się w requeście, wtedy zabezpieczenie jest konieczne. Jeśli nie ma takiego sposobu, czyli np. łączysz się ze swoim API po stronie serwera, wtedy wystarczy np. prosty klucz API.
5. Tak, mam wskazówkę - zrozum dlaczego, jak i po co. Ogarnij protokół HTTP - metody, statusy, nagłówki, formaty danych. Wtedy temat przestanie być dla Ciebie czarną magią.

Nie ma za co, Marku

Sam Slim jest na tyle prosty że chyba się nie pomylę jeśli powiem że w dzień można go spokojnie ogarnąć. A może https://apigility.org/

Slim nie jest typowym frameworkiem, jest mikro frameworkiem. Ktoś powie, że to jest to samo, ale to nie prawda. Na mikro frameworku nic dużego nie zbudujesz, a jakbyś jednak zbudował, to utrzymanie tego będzie ciężkie. Jeżeli API ma być małe, lekkie, bez większej logiki to Slim się sprawdzi. Jeżeli API będzie kombajnem, to Slim zdecydowanie się nie sprawdzi. Coś czuję, że próbujesz dobrać problem do narzędzi (Slim), ale pewnie się mylę.

@SmokAnalog
1. To jak ty byś zaczął?
Nie wiem też jak to powinno wyglądać całościowo, czy lepiej zrobić API jako całkowicie osobną aplikację, np. na subdomenie api.example.com i łączyć się przez coś typu Guzzle, czy jednak w jakiś sposób to połączyć, robić np. pod example.com/api/ Dodatkowo nie wiem jak połączyć samą stronę z API, czy zrobienie przykładowo strony która przez sam JS będzie pobierała dane z API ma jakiś sens, czy lepiej normalnie napisać osobną aplikację? A może jakoś wbudować tą aplikację w API? Sam nie wiem jak tą taką całość ogarnąć.
4. Dopóki będzie to sama strona w backendzie to chyba nie ma problemu, mogę dać ukryty klucz którego nie będą widzieli użytkownicy i sprawdzać go w API, ale jeśli wejdą jakieś zapytania z JS albo z aplikacji mobilnych to chyba to już trzeba jakoś inaczej rozwiązać. Nawet jeśli to nie jest proste na dwa zdania opisu to mógłbyś chociaż podrzucić jakiś link z opisem jak coś tego typu zrobić czy coś?
2, 3 i 5 dziękuję


@viking faktycznie, dopiero co zacząłem i właściwie wszystko co jest u nich na stronie już w miarę ogarnąłem. Apigility jak widzę bazuje na frameworku Zend, czy to nie będzie więc jakieś bardzo ciężkie? Będzie to raczej małe API i mała strona. Nie znam tego Apigility więc nie wiem jak tam sprawa wygląda.

@lukaskolista zgadza się, wiem o tym. API ma być małe i lekkie, wydaje mi się, że Slim się nada. Problemu do narzędzi raczej nie próbuję dobierać, chociaż nie wiem. Szukam po prostu wskazówek jak zrobić przyzwoite i nieźle działające API, framework nie jest aż tak istotny.

Jak zrobić dobre API? Przede wszystkich wystawiać precyzyjne kontrakty i później ich nie łamać. Dodatkowo obsługa API przez klienta powinna być prosta i do wykonania jednej akcji nie powinno być konieczne odwołanie do API więcej, niż 1 raz. Dobór technologii dowolny, zależny od tego, czego potrzebujesz.