RESTful API w php?

0

Witam!
Jako że to teraz taki modny temat :D to postanowiłem go zgłębić i sam napisać jakieś api. Nie chce póki co robić tego w Javie (choć z obserwacji zauważyłem że najwięcej takich w niej się robi). Czy PHP jest dobrym językiem do tych celów?

Jeżeli tak to ma ktoś z was moze jakieś dobre materiały z których można by było to pojąć. Oczywiście jest google, które już prześledziłem dokładnie. Roi się tam od pseudo-tutoriali, w których każdy pseudo-bloger-coach robi to w inny sposób. Za to wideo tutoriale nagrywane są w większości przez ciapatych i nie idzie ich zrozumieć :D. Nie chciał bym nabrać złych nawyków.

0

@spartanPAGE dzięki stary, mam u Ciebie dług wdzięczności, zapomniałem adresu googe. Podleczyłeś kompleksy?

Nie pisałem nic o frameworku... chodzi mi bardziej o jakieś materiały, które pomogły by mi zrozumieć tą architekturę. Na google znaleźć można ich od groma, ale czy ktoś ma jakieś godne polecenia?

0

Na edx trwa jeszcze kurs Engineering Software as a Service w RoR, ale sama koncepcja architektury jest niezależna od języka.
Filmy ze szkolenia dostępne są na yt

3

Zajmuje sie tym tematem zawodowo na duza skale, np systemy dzialajace w obrebie calego kontynentu, przetwarzanie, transakcje itp. I tak, pehap nadaje sie do zrobienia bezstanowego(!) api, ktore jest nakladka na jakas baze itp. Czyli "robi zapytanie", przewala do jsona i wypluwa na wyjscie. To jest proste.
Natomiast pehap jest tragiczny jezeli owo api ma cokolwiek przetwarzac, zupelny brak asynchronicznosci na jakimkolwiek poziomie.

Wiec jak chcesz napisac proste api, to walcz. Osobiscie mysle, ze wiekszosc frameworkow z pehapa nie daje ci zupelnie nic jezeli chodzi o pisanie api, sa jedynie wolnym narzutem.

Jak chcesz cos w swoim api przetwarzac to duzo lepsza technologia bedzie chociazby python, w ktorym masz celery podpiete pod kolejke na amqp lub redisie, oraz flask ktory doskonale sie z tym integruje. Z innych wynalazkow to chociazby scala i akka.io.

0
cepa napisał(a):

Natomiast pehap jest tragiczny jezeli owo api ma cokolwiek przetwarzac, zupelny brak asynchronicznosci na jakimkolwiek poziomie.

Przetwarzać w jakim sensie? Podasz jakiś przykład? ;)

1
mwns napisał(a):
cepa napisał(a):

Natomiast pehap jest tragiczny jezeli owo api ma cokolwiek przetwarzac, zupelny brak asynchronicznosci na jakimkolwiek poziomie.

Przetwarzać w jakim sensie? Podasz jakiś przykład? ;)

Wszelkie operacje, które powodują zapisy, przykładowo obsługa zamówień w dużym systemie, gdzie jest integracja z systemami księgowymi, płatnościami, mailingiem, supportem. Takie coś nie robi sie w czasie zycia requestu, tylko odklada na kolejke i przetwarza asynchronicznie ze wzgledu na opoznienia i kilka puntkow integracji / awarii. Samo 'api' jest wtedy jedynie routerem ktory odklada zadania do kolejki, a z tylu backend przetwarza je i skaluje sie go wzgledem architektury persisetnce. Np: uzywasz MySQL czy RDS na amazonie i wydajnosc tego jest dość niska, a moze byc znacznie wiecej transakcji w czasie niz przepustowosc.

Da sie to zrobic w pehapie, np: z rabbitmq albo gearmanem, ale jest to i tak klepanie kodu od zera. Dodatkowo masz wtedy procesy pehapa ktore dzialaja w tle i samo zarzadzanie nimi to dramat, zarzadzanie pamiecia kuleje, wykrywanie problemow jak rozlaczanie uslug, restarty itd - problem, brak poolingu - problem. W celery i bardziej zaawansowanych technologiach, takie rzeczy masz wbudowane we "framework" wiec skupiasz sie na problemie, a nie na budowaniu samego systemu kolejki.

0
cepa napisał(a):

Da sie to zrobic w pehapie, np: z rabbitmq albo gearmanem, ale jest to i tak klepanie kodu od zera. Dodatkowo masz wtedy procesy pehapa ktore dzialaja w tle i samo zarzadzanie nimi to dramat [...]

Na razie nie spotkałem się z przypadkiem, by przetwarzając elementy z np. SQS problemem było współistnienie kilku procesów (może się kiedyś spotkam). Kolejka z zasady dba o to, by procesy nie przetwarzały tych samych informacji. Pełna zgoda co do reszty wypowiedzi.

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