Dotychczas miałem doświadczenia ze starszymi frameworkami, np. Codeigniter.

Dlatego trudno mi zrozumieć wiele rzeczy w tych nowszych, jak Laravel czy Slim.

W Codeigniter mogłem po prostu stworzyć kontroler "blog" i metodę "new_post" - i to wszystko, po wpisaniu tego w pasku adresu (example.com/blog/new_post) strona była otwarta.


Mogłem w tej metodzie wypluć formularz dodawania nowego postu, lub, jeśli okazało się, że są jakieś dane w POST, to dodać nowy post do bazy danych i ewentualnie gdzieś przekierować.

Oczywiście też były routy, np. można było zrobić coś takiego:
$route['strona/(:any)'] = 'pages/show/$1';


A w Laravel i wielu innych muszę definiować routy dla każdego kontrolera i każdej akcji i to jeszcze w rozdzieleniu na typ requestu http (post,get,delete etc). Czyli muszę zrobić takie coś:







Tzn. w Laravel jest chyba skrót, Route::resource, ale i tak trzeba to dodać do routes.

Takie frameworki potem chwalą się, że są RESTful. Zdaje się, że tak twierdzą właśnie ze względu na te routy.

Możecie mi powiedzieć w jaki sposób to ułatwia życie?

Zacząć należało by od tego, że REST nie ma nic wspólnego z tym, czy masz domyślne routowanie czy nie. Poczytaj co to jest REST. To nie routing

O powody takiego, a nie innego podejścia zapytać musisz twórców frameworka. Ale mogę tylko zgadywać, że to jest bardziej kwestia bezpieczeństwa. Ponieważ routing w przypadku CI działa na zasadzie konwencji łatwiej jest o dostęp do nieodpowiednich kontolerów. Poza tym może być jeszcze kwestia przejrzystości. Jeśli każdy routing mam zdefiniowany, to łatwiej się do niego odnieść w innej części kodu. Jeśli wszystko jest robione na zasadzie konwencji, to musisz zawsze samemu pamiętać, jak URL ma wyglądać, żeby się dostać do danego kontrolera. Ewentualna modyfikacja jest prostsza, bo masz kontoroler identyfikowany po nazwie a nie strukturze katalogów czy innej konwencji. Konwencja to IMHO magia i powinno się jej unikać jak ognia. No chyba, że nie ma za bardzo innego wyjścia albo można przy użyciu solidnych argumentów ją umotywować .

A o szczegóły takiej a nie innej decyzji polecam zapytać twórców, oni to na pewno wyjaśnią najlepiej.

W nadchodzących frameworkach będzie jeszcze ciekawiej. Wszystko zmierza w kierunku PSR-7 i middlewares.

@Xelah

Dzięki. Ma to jakiś sens, ale zastanawia mnie jedno. Chcemy użyć zewnętrznego modułu, np. Blog, i oprócz skopiowania po prostu paru plików (kontrolery, widoki) to musimy jeszcze bawić się w routy. Do tego, gdy ten blog będzie zaktualizowany, to musimy te routy też zaktualizować. I wciąż nie wiem jakim cudem te zalety skomplikowania routów w Laravelu "wygrywają" z podejściem Codeigniterowym...



No chyba wiem co to jest REST - requesty HTTP mają swoje metody, jak właśnie GET czy POST oraz jakieś tam dane - i my działamy zgodnie z tą metodą i danymi, no chyba do tego to się sprowadza, tak?

W takim razie, co takiego mają te nowe frameworki (jak np. Laravel), że chwalą się, że są "RESTful"?

@viking


Nie no, jak dla mnie to za dużo naraz , na razie chciałbym nadrobić ostatnie lata zmarnowane na codeigniterze i zrozumieć koncepcje stojące za nowszymi frameworkami.

REST nie ma nic wspólnego z routingiem, to tylko wzorzec na komunikację klient -> serwer

Tak jak napisałem wcześniej - wprowadzanie konwencji do aplikacji. Aplikacja (a wszczególności routing) nie powinny działać na zasadzie konwencji. To jest hard-coupling pomiędzy strukturą folderów, nazwami plików, klas i metod. To jest czyste zło. Kontorler powinien być niezależny, a nie wymuszony przez konwencję. Nie wiem, jak to działa w CI, bo pracowałem z nim raz i to jakieś 5 lat temu, więc najzwyczajniej w świecie nie wiem, jak to działa w obecnej wersji.
Jeśli już mówisz o kopiowaniu gdzieś całego modułu, to jego częścią powinien być routing. I wtedy dalej nie musiłbyś się martwić. Jeśli nie jest, to jest to tylko i wyłącznie wina architektury albo CI albo tego modułu. Jeśli pozwalają na reuse to routing powinien być jego integralną częścią. Wtedy problem po prostu nie istnieje.
Tak to mniej więcej wygląda w bundlach Symfony. Jeśli bundel potrzebuje routingu, to jest on jego integralną częścią i nie musisz się o niego martwić używając go w tym czy innym miejscu.



Miej więcej
https://en.wikipedia.org/wiki/Representatio..._state_transfer



Ja bym strzelał, że jedyne, co je rzeczywiście wyróżnia, to dobry marketing
Silex jest bardzo prostym frameworkiem i można by pokusić się o stwierdzenie, że nie jest tak napompowany jak Symfony czy Zend. A przez to lepiej się nadaje do API, bo potrafi teoretycznie obsłużyć więcej requestów. Reszty nie znam, więc nie będę się wypowiadał.

Generalnie nie ma większej różnicy jaki framework wybierzesz. REST-ową aplikację możesz zrobić zawsze. Całkiem możliwe, że łatwiej będzie to zrobić w tym czy innym frameworku ze względu na jego budowę, ale to już są raczej detale. Request i response to ułamek (dosłownie) tego, co zazwyczaj się dzieje pomiędzy request-em a response. Najważniejszy jest model domeny. Potem będzie (zazwyczaj) persistance (nie ważne czy baza czy coś innego). To stanowi jakieś 99,9% całego API.


A najlepszy framework do REST-a możesz sobie zawsze napisać sam. Wtedy będzie najoptymalniejszy wydajnościowo i bez jednego zbędnego wodotrysku Nam to zajęło w sumie 4 dni (dwie osoby). Mamy własny kod i używamy komponentu walidacji z Symfony i mamy adapter do obiektu Request z Symfony, żeby uniezależnić się do konkretnej implementacji i mieć tylko to, czego potrzebujemy. Reszta to kod własny: Response, rendering, obsługa błędów, routing i kontrolery (na zasadzie CQRS). Testowy czas wykonania pojedyńczego requestu typu hello world (z walidacją requestu i jakąś banalną logiką) to całe 4ms-6ms. Dupy nie urywa, ale do REST wystarczy
Tylko pytanie czy czujesz się na siłach pisać wszystko od podstaw samemu

@Xelah
Dzięki!

Zajrzałem do pierwszego lepszego bundla Symfony ( https://github.com/FriendsOfSymfony/FOSUserBundle ) i faktycznie, są tam routy.

Eh, dużo jeszcze nauki przede mną, za dużo czasu spędziłem na CodeIgniter.

W Laravel istnieje wiele możliwości definiowania route.
Począwszy od zwyczajnego get, post, put,delete, poprzez Resources, Controller po rózne uogólnienia typu Any.

W Laravel definiowanie konkretnych route daje Tobie jako programiście większą kontrolę nad dostępem do zasobu.
Tworząc route typu DELETE będziesz wiedział że nie dobierzesz się do niego przez GET.

Tutaj dochodzimy do RESTfull. Posiadając Rout z ograniczeniem dostępu do metody HTTP nie musimy sprawdzać tego w metodach. W połączeniu z middleware mamy cuda.

Co do samego RESTfull to tak, generalnie marketing, ale i nie do końca.
W Laravel utworzenie prostego API w stylu REST to utworzenie 1 Route (Resource) dla klasy i odpowiedniej klasy z metodami. Sam FW ma generatory które to ułatwiają.

Na koniec kwestia Paczek i Route.
Jak zauważyłeś na podstawie Bundla Symfony (nie mylić ich z paczkami Laravel) to każda taka paczka powinna zawierać w sobie kompletny twór czyli szablony, config, route (o ile tego wymaga). To paczka dba o to żeby to zawierać i nie martwić się co z aktualizacjami.
Oczywiście jeśli chcesz to możesz nadpisać (chyba że ktoś zakodował na sztywno url ) i mieć swoje. Droga wolna