Tworzenie API w PHP, początki

0

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ą nawet najmniejszą pomoc, jest to dla mnie bardzo ważne.
Pozdrawiam, Marek

0
  1. Jeżeli potrzebujesz webowy front i apkę mobilną, a backend ma być wspólny dla nich, to API jest wtedy używane pewnie w 95% takich przypadków. Wystawiasz API, do którego łączysz się z frontu przy pomocy czystego AJAX'a lub jQuery, gdy jest to API na 2-3 zasoby. Inaczej ogarnij sobie jakiś framework JS do tego.
  2. Wydawałby się spoko, ale to taki minimalistyczny framework, dużo będziesz musiał jeszcze pewnie zassać z composera.
  3. Na początek MySQL może być łatwiejsze, ale to bez większej różnicy. Jak będziesz miał od razu jakiś ORM podpięty, to zyskasz dużo czasu na pisaniu i testowaniu kwerend i cała warstwa dostępu do bazy będzie dużo chudsza (tylko odpalanie metod na modelach ORM).
  4. Możesz generować klucze jednorazowego użycia (per sesja) albo udostępniać je (API) tylko dla zalogowanych użytkowników. W pewnym sensie cokolwiek, co wystawisz publicznie w sieci może być używane poza dedykowanym frontem.
  5. Poczytaj po prostu o REST API w sieci. Korzystaj z odpowiednich http verb i nazywaj odpowiednio zasoby i akcje na nich. W necie do poczytania chociażby.

Zasadniczo REST API, router w PHP, ORM i coś do korzystania z API w JS, a resztę to już w zależności od wymagań i założeń projektu samego w sobie.

0

Dziękuję za odpowiedź!
Ad 1. Dokładnie tak potrzebuję, nie wiem jednak czy po stronie frontu ma być to same połączenie z JSa, czy może osobna aplikacja również w PHP łącząca się przez backend z tym API.
Ad 2. Faktycznie, wydaje się mały i skromny. A co poleciłbyś innego? Czego warto się nauczyć i jednocześnie nadało by się do projektu tego typu?
Ad 3. Rozumiem, czyli ORM, ale nie za bardzo wiem czy np. taki Eloquent czy może Doctrine, mógłbyś coś poradzić?
Ad 4. Część rzeczy jak najbardziej będzie tylko dla zalogowanych, ale nie ma sposobu, aby zabezpieczyć całość? Klucze sesyjne chyba tu nie pomogą, bo jak ustalę czy dana osoba może się łączyć z API czy nie? Chciałbym, aby połączenie z API było możliwe np. tylko z mojej strony www i z moich aplikacji mobilnych.
Ad 5. Ok, będę szukał.

0

Ja polecam yii2 do tworzenia restowego api. łap http://www.yiiframework.com/doc-2.0/guide-rest-quick-start.html

0
  1. Zdecydowanie częściej będzie to API na tym samym serwerze z tym samym entry-pointem, tylko URL'e będą poprzedzone mniej więcej przez jakieś /api/v1/[...]. Wtedy JS komunikuje się bezpośrednio z API, które na dodatek wiele komponentów/klas dzieli z całą apką na serwerze.
  2. Slim i do tego jakieś paczki z packagist powinny wystarczyć. Jeśli potrzeba większej apki, to laravel lub symfony. Tam jest już mnóstwo przydatnych klas i komponentów.
  3. To raczej bez różnicy. Ale Eloquent będzie chyba łatwiejszy na początek, znając go, od razy łatwiej będzie z laravelem, gdyż on z niego domyślnie korzysta, natomiast symfony to raczej doctrine.
  4. Możesz pobawić się z CORS i nałożyć na to odpowiednie restrykcje, ale to co publicznie wystawione do sieci, zostanie publiczne. Jeżeli nie będzie kluczy, czegoś może nawet pokroju CSRF (dałoby się tutaj zaaplikować, choć do obejścia) i w szczególności logowania dla użytkowników, to wtedy można napisać cokolwiek, co się z tym API połączy. To lekkie uproszczenie, ale jeżeli API dostaje JSON'a z dwoma liczbami, np. {"numbers": [1, 2]} i zwraca ich sumę, a każdy gość na stronie głównej ma mieć dostęp do tej akcji w API, to niezbyt da się to zabezpieczyć. Zapytania do API mogą być fabrykowane z różnych serwerów, które robią za proxy między nowym frontem, a oryginalnym API.
0

@SekretarzGeneralnyONZ dzięki, chociaż do tej pory jakoś nie brałem Yii pod uwagę, nawet jak patrząc przyszłościowo przeglądałem czego jest dużo na rynku pracy to widywałem np. Symfony, Zend (ale nie wiem czy to nie są za duże frameworki na start i na niezbyt duże API?) albo Laravel (tutaj z kolei czasem słyszałem złe opinie, że to niby słaby FW, ale nie wiem może to tylko jakieś gadki były). Na razie to odległe plany, ale tak sobie myślę, że warto się uczyć czegoś co potencjalnie może też się później przydać. Slima co prawda nigdzie też nie widziałem, no ale to taki mały framework, że w zasadzie podstawowe możliwości już ogarnąłem, a coś większego chciałbym ogarniać co mi się przyda ewentualnie.

@Świetny Szczur

  1. Może to głupie pytanie, ale co jak ktoś wyłączy obsługę JS? To strona mu całkowicie nie zadziała bo dane się nie pobiorą z API (bo jeśli dobrze rozumiem to mają być pobierane tylko przez to JS z API)? Wiem że w praktyce raczej nikt nie wyłącza JS, no ale kto wie, nie wiem jak powinno być to zrobione dlatego dopytuję bardziej doświadczonych :)
  2. Okej, Symfony wydaje mi się spore i dość trudne, jakoś bardziej przyjazny wydaje się Laravel chociaż o nim jak pisałem wyżej słyszałem jakieś mieszane opinie. Sam jeszcze nie wiem, dzięki za radę.
  3. Rozumiem, więc postawię raczej na Eloquent.
  4. Czyli chyba nici z tego, teoretycznie logowanie też ktoś może chyba bez problemu zrobić ze swojej aplikacji i podłączyć pod to moje API :/ A co z OAuth, ogólnie to by mi się przydało, nie wniosło by nic w tej kwestii?
    I dzięki za pomoc.
0

Może to głupie pytanie, ale co jak ktoś wyłączy obsługę JS?

Nie przejmuj się paranoikami, to znikomy ułamek użytkowników - nawet google ich olewa.

0

Tutaj jest taki przykład, z tym że REST server jest w pythonie a nie w PHP. Jest to taka prosta aplikacja TODO List z wykorzystaniem Knockout.js, mówię o części klienckiej.
https://blog.miguelgrinberg.com/post/writing-a-javascript-rest-client

Co do frameworków to obawiam się że kolejny temat na toczenie wojenek odnośnie wyboru jednego z nich :-)

Powyższy przykład działa w oparciu o Basic Authentication, w celu uwierzytelnienia, wypluwane dane są JSON-owe i to jest obrabiane przez ten Knockout.js

Nie wiem na ile jest wykorzystywany ten Knockout, podejrzewam że jest mało popularny ale na podstawie kodu dość łatwo zrozumieć o co tu chodzi. Oczywiście jasne, wyłączenie JS i aplikacja nie działa. Tylko tak się zastanawiam czy jest to dzisiaj wada? To już chyba nie te czasy kiedy się pracuje z wyłączonym Java Scriptem.

0

@Maciej Cąderek okej, dzięki.

@drorat1 Nie chcę kolejnych wojenek bo wiem że przeważnie każdy poleci to z czego korzysta, dodatkowe część osób zhejtuje laravela i na tym się skończy. Po prostu zapytałem czy ktoś poleca coś innego jeszcze.
Wspomniałeś o "Basic Authentication", czy to wystarczy do zrobienia logowania w API czy trzeba jakoś dodatkowo to zabezpieczać?

0

Wysyłasz login i hasło zakodowane przez Base64 (kodowanie transportowe) przez nagłówek HTTP, trzeba by użyć połączenia HTTPS. Są inne metody, możesz stosować np. jakieś klucze dostępu czy inne tego typu rzeczy, zależy co konkretnie chcesz zrealizować.

http://stackoverflow.com/questions/3464454/https-and-basic-authentication

0

Nic specjalnego, potrzebuję po prostu zwykłej rejestracji i logowania, dla osoby zalogowanej mają być zwracane z API określone rzeczy, a dla niezalogowanej tylko część z nich. Czy samo to Basic authentication z użyciem HTTPS mi wystarczy?

1 użytkowników online, w tym zalogowanych: 0, gości: 1