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?

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?

do góry

On 2012-05-01, Jacek Czerwinski <...@...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

do góry

W dniu wtorek, 1 maja 2012 10:19:00 UTC+1 użytkownik Stachu &#39;Dozzie&#39; K.
napisał:

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

Ilekroć mowa o SOAP, nie mogę sobie odmówić przyjemności przytoczenia tego odnośnika:

http://www.shlomifish.org/humour/by-others/s-stands-
for-simple/

--Daniel

do góry

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

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

Właśnie, kilkakrotnie miałem kontrakt z XML-RPC i nie mam uczulenia po
tym. Dziś to takie ... niemodne ;)

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

1.W sumie tak, JSON-RPC.

2. Argumenty tzn skoro takie to modne ... gdzie był ten punkt, że
uzyskało przewagę (oprócz dopasowania do AJAX-a). Większość
konsumenckich webserwisów idzie na tym lub czymś podobnym.

Bu nie zacytować popularnego zdania o milionach much ..

do góry

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

do góry

On 2012-05-01, Jacek Czerwinski <...@...z.pl> wrote:
> W dniu 2012-05-01 11:19, Stachu 'Dozzie' K. pisze:
>> On 2012-05-01, Jacek Czerwinski<...@...z.pl> wrote:
>
>> 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).
>
> Właśnie, kilkakrotnie miałem kontrakt z XML-RPC i nie mam uczulenia po
> tym. Dziś to takie ... niemodne ;)

Co, brak uczulenia niemodny? Nie wiem. Wiem za to, że sporo narzędzi,
z którymi się spotykam jako admin, pozwala na korzystanie z nich przez
XML-RPC. Znacznie mniej potrafi SOAP, a REST jest właściwie tylko do
pobierania danych, a nie do dwustronnej komunikacji.

>> Czy przez "JSON" rozumiesz tu protokół "JSON-RPC"? I jakie argumenty
>> masz na myśli?
>
> 1.W sumie tak, JSON-RPC.
>
> 2. Argumenty tzn skoro takie to modne ... gdzie był ten punkt, że
> uzyskało przewagę (oprócz dopasowania do AJAX-a). Większość
> konsumenckich webserwisów idzie na tym lub czymś podobnym.

"Lub czymś podobnym". Czyli właściwie nic ustandaryzowanego, przez co
żeby tego użyć trzeba samemu rzeźbić. No i brak bibliotek do obsługi.

JSON-RPC byłby bardzo fajną rzeczą, gdyby był powszechniejszy. Nie jest,
więc dla mnie XML-RPC jest najwłaściwszym rozwiązaniem. Najłatwiej go
użyć i rzadko sprawia problemy.

> Bu nie zacytować popularnego zdania o milionach much ..

Żeby jeszcze te muchy jadły to samo.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2012-05-01, Jacek Czerwinski <...@...z.pl> wrote:
> 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,

Oj, owszem, jest pożytek, i to spory. JSON jest niezłym formatem do
transportowania danych. Jest dużo prostszy od XML-a, zwarty
i jednoznaczny. Łatwiej go ręcznie edytować, produkować i przetwarzać
niż XML.

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

Dunno, ja się obracam wokół języków skryptowych.

--
Secunia non olet.
Stanislaw Klekot

do góry

> Pytanie: jakie są dobre biblioteki JSON do C#

Odnośnik do jednej z nich, ale znajdziesz tam też porównanie w stosunku
do innych.

- http://www.codeproject.com/Articles/159450/fastJSON

--
Mateusz Bogusz

do góry

Stachu 'Dozzie' K. <d...@g...eat.some.screws.spammer.invalid> napisał(a):

> On 2012-05-01, Jacek Czerwinski <...@...z.pl> wrote:
> > 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,
>
> Oj, owszem, jest pożytek, i to spory. JSON jest niezłym formatem do
> transportowania danych. Jest dużo prostszy od XML-a, zwarty
> i jednoznaczny. Łatwiej go ręcznie edytować, produkować i przetwarzać
> niż XML.
Mam odwrotne wrażenie. Wydaje mi się że pod tym względem XML ma lekką
przewagę nad JSON.
Pozdrawiam


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On Tuesday, May 1, 2012 2:54:32 PM UTC+1, Stachu &#39;Dozzie&#39; K. wrote:
> Oj, owszem, jest pożytek, i to spory. JSON jest niezłym formatem do
> transportowania danych. Jest dużo prostszy od XML-a, zwarty
> i jednoznaczny. Łatwiej go ręcznie edytować, produkować i przetwarzać
> niż XML.

W firmie w ktorej pracowalem JSON byl uzywany do przesylania wstepnie przetworzonych
danych rynkowych z serwera cache do stacji roboczych analitykow, wlasnie dlatego ze
byl prostszy i szybszy w parsowaniu niz XML. Jest tak prosty, ze moglismy go
zaladowac dane w formacie JSON do Excela, analityk je sobie zmienial jak chcial i
wrzucal z powrotem w model obliczeniowy. Z XML byloby wiecej rzezby.

RW

do góry