W dniu 2012-05-01 11:19, Stachu 'Dozzie' K. pisze:
> On 2012-05-01, Jacek Czerwinski<...@...z.pl> wrote:

> 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ć.

Cachowanie tak ...

W jakimś spojrzeniu "fajne", czy "sprytne" jest wykorzystanie komend i
kodów powrotu HTTP. Czy "sprytne" to dowód jakość czy dojrzałości ...
nie mam dystansu do własnego zdania. Akcja, coś, co w "starych"
protokołach było bardziej wewnątrz koperty niż na zewnątrz (a HTTP
niewiele więcej niż rurą czy kanałem, nośnikiem) , tu Akcja jest
wyraźnie na zewnątrz.

Ja w REST odnajduję mocno dojrzały etap "samoróbnych" webserwisów, gdzie
jedynym standardem była umowa programistów jakiego GET'a sobie wykonamy.
Czasem przydatne są aż tak proste rozwiązania. Kiedyś tak z kumplem
zadawaliśmy i sprawdzaliśmy temperaturę mikrokontrolera do systemu
kaloryferów. Żadnych bibliotek ponadstandardowych.
I na tej ścieżce, zwracanie odpowiedzi JSON jest "jakąś" propozycją jak
zwracać bardziej złożone dane, co kiedyś nie było żadnej inspiracji jak
to zakodować.
Akurat językowo pozostając poza JavaScriptem nie na specjalnie z tego
JSON pożytku, ale pewnie programiście który integrował się z portalami
jest to znajome. Pewnie, skoro najwięksi to robią, są jakieś sprawdzone
biblioteki...

Pytanie: jakie są dobre biblioteki JSON do C#, Javy i C++.