🚀 go-pugleaf

On 2012-05-01, Jacek Czerwinski <x@y.z.pl> wrote:
> Potrzeba zintegrowania sporych projektów z Javie i .NET (nie wykluczając 
> pomniejszych w C++/MFC) skłoniła mnie do myślenia przy leniwiej kawie o 
> webserwisach.
> Lat temu kilka by się budowało jakiś deskryptor usługi, SOAP itd.
>
> Jak widzę rosnącą ilość API REST/JSON, myślę czy by się w tym nie 
> podszkolić. Moje interfejsy to na początek udostępnienie jednej głupiej 
> klasy obiektu (w sensie REST), a docelowo najwyżej 4-5  klas, kolekcji.
>
> Co do REST, to jest więcej mody, czy twarde argumenty?
> Ja to postrzegam w postaci dalekiej analogii pomiędzy językami 
> kompilowanymi a skryptowymi, bardziej podatne do zrobienia 'na kolanie'. 
> Dobrze myślę? Czego nie wiem?

Z punktu widzenia użytkownika[*] systemu: REST ma sens, gdy udostępniasz
dane przeszukiwalne za pomocą jakichś kryteriów i hierarchicznie
uporządkowane, i to najlepiej takie, które nie zmieniają się specjalnie
często. Dzięki temu można je cache'ować. Ale to na ciebie spada
obowiązek przygotowania formatu serializacji podawanych danych, ty
musisz ustalić, jak sygnalizować błędy, a na dodatek użytkownik musi
twoje metody sygnalizacji błędów i podawania danych obsłużyć.

Osobiście wolałbym XML-RPC albo ewentualnie SOAP (w tej właśnie
kolejności; ten pierwszy jest prostszy pojęciowo i IMO prostszy od
strony wywołującego w użyciu).

[*] Użytkownik jest administratorem, który na przykład potrzebuje
monitorować twój system albo wyciągać z niego jakieś informacje.

> W każdym razie to moje przyszłe dzieło, nie ma nic wspólnego z AJAX-em, 
> JS (ani PHP), czy argumenty za JSON dalej są ważne?

Czy przez "JSON" rozumiesz tu protokół "JSON-RPC"? I jakie argumenty
masz na myśli?

-- 
Secunia non olet.
Stanislaw Klekot

> Co do REST, to jest więcej mody, czy twarde argumenty? Ja to postrzegam w 
> postaci dalekiej analogii pomiędzy językami kompilowanymi a skryptowymi, 
> bardziej podatne do zrobienia 'na kolanie'. Dobrze myślę? Czego nie wiem?

Jak już kolega wcześniej napisał idea REST to filozofia czterech operacji 
CRUD wykonywanych na trwałym bycie określonym poprzez URL. Przekłada to 
środek ciężkości logiki biznesowej na klienta. Usługa REST jest bardziej 
repozytorium danych niż serwisem biznesowym. Json jest zaś bliższy temu o 
czym piszesz - luźny, "skryptowy" opis danych, możliwy do błyskawicznego 
wczytania przez javascriptowy eval(), bez kosztownego czasowo parsowania. 

W dniu 2012-05-07 07:28, William Bonawentura pisze:
>
>
>> Co do REST, to jest więcej mody, czy twarde argumenty? Ja to
>> postrzegam w postaci dalekiej analogii pomiędzy językami kompilowanymi
>> a skryptowymi, bardziej podatne do zrobienia 'na kolanie'. Dobrze
>> myślę? Czego nie wiem?
>
> Jak już kolega wcześniej napisał idea REST to filozofia czterech
> operacji CRUD wykonywanych na trwałym bycie określonym poprzez URL.

Jasne. Dla mnie "świeże" w tym pomyśle jest intensywne wykorzystanie 
cech HTTP (4 polecenia http wprost zastosowane) i pewnie (?) kody 
powrotu, spotkałem to w opisie którejś z bibliotek (nie wiem czy jest to 
powszechne).
(Podobnie jak kilka implementacji ma koncepcje pojedynczego wyniku i 
kolekcji, też nie wiem czy to "przenośne" skoro nie jest to mocno objęte 
standardami ...)

Jak kilka razy się robiło "ręcznie" (na różnych dziwnych 
architekturach), łatwo się odnaleźć.

W dniu 2012-05-07 07:28, William Bonawentura pisze:
> Json [...]możliwy do
> błyskawicznego wczytania przez javascriptowy eval(), bez kosztownego
> czasowo parsowania.

Eval jest passe. :-)
Wspolczesne przegladarki maja wbudowana metode JSON.parse(), dla staroci 
pozostaje np. jQuery.parseJSON()

-- 
NotBear