🚀 go-pugleaf

... W dole szumi rzeka, w górze fruwa ptak
A RobertSzefler sobie idzie i śpiewa sobie tak:

>>>>... a może po prostu są inne. Jeśli WWW ma wykorzystywać swoje własne cechy
>>>>architekturalne, paradygmatem powinien być REST, nie SOAP. Całość stanu
>>>>wbudowana w strony serwisu, traktowanego jako graf stanów reprezentowanych
>>>>zasobów. http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
>>>
>>>A powiedz, dlaczego ludzie jak programują, to projektują raczej ręcznie 
>>>automatów stanów, tylko używają regexów albo języków, czy to 
>>>imperatywnych, czy funkcyjnych? To z reguły jest prostsze... (oczywiście 
>>>nie zawsze)
>> 
>> A skoro nie zawsze, skąd wiesz że tak byłoby w tym przypadku?
> 
> To oczywiście nie jest argument, bo milion much może się mylić. Ale jak 
> masz duży serwis z mieszanką zawartości statycznej, średnio- i wysoce 
> dynamicznej, to większość ludzi używa sesji jako (równoważnego 
> oczywiście użyciu automatu stanów) identyfikatora aktualnego stanu, bo 
> to umożliwia w większym stopniu skupienie się na lokalnych własnościach 
> problemu, a nie patrzenie na system jako całość. Ja nie mówię, że to 
> lepsze, chociaż większość serwisów, które robiłem, przy użyciu 
> paradygmatu REST byłoby zrobić *znacznie* trudniej.

Być może tylko ze względu na przywyczajenia. Popatrz na sąsiedni wątek, gdzie
idzie dyskusja o frameworkach webowych - jakoś nie masz w niej problemu ze
spojrzeniem na całość i operowaniem dość złożonymi pojęciami w celu
argumentowania, dlaczego dana architektura oprogramowania ma sens, a inna nie.
Dlaczego akurat REST miałby być barierą nie do przejścia? Kwestia
przyzwyczajenia do określonych założeń. A pożytki z takiego podejścia naprawdę
duże - globalnie i lokalnie.

-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>