Co to jest i po co używać formatu JSON w aplikacjach IOT?

[_LM_]

Takie zapytanie, dlatego że jest niezerowa szansa że ktoś szybciej i łatwiej mi to wytłumaczy, czy ten format jest "obowiązkowy"? Dlaczego jest (lub nie jest) lepszy od własnych komend wysyłanych z aplikacji? 

[ethanak]

17 minut temu, _LM_ napisał:

Takie zapytanie,

No więc może najpierw co to jest. Za Wikipedią:

Cytat

JSON (JavaScript Object Notation, pronounced /ˈdʒeɪsən/; also /ˈdʒeɪˌsɒn/) is an open standard file format and data interchange format that uses human-readable text to store and transmit data objects consisting of attribute–value pairs and arrays (or other serializable values).

To już powinno wszystko wyjaśnić. Pytasz czy jest obowiązkowy... nie, nie jest, ale nie znam żadnego programisty który nie zna notacji JSON (przynajmniej ogólnie) i nie potrafi używać bibliotek do serializacji/deserializacji tej notacji. Po prostu jeśli zastosujesz jakis własnościowy sposób kodowania do czegoś bardziej skomplikowanego niż przesłanie prostego polecenia typu "komenda - parametr" jest duża szansa, że ktoś kto będzie to przerabiał/poprawiał/rozbudowywał nie będzie chciał nawet na to patrzeć. Taki prosty przykład:

{
  "zapal": {
    23:[255,255,255],
    47:[255,0,0],
    423: [0,0,255]
  }
}

        

Masz tu mozliwość zapalenia jakichś tam diod w konkretnym kolorze. To jeszcze można od biedy jako pojedyncze polecenie zrobić, ale wyobraź sobie polecenie bardziej skomplikowane... że juz nie powiem o przesyłaniu jakichś bardziej skomplikowanych struktur (np. przesłanie danych z zespołu czujników).

Ogólnie: tam gdzie jest konieczna serializacja danych (czy to polecenia, czy odpowiedzi na polecenie) JSON jest formatem uniwersalnym, niezależnym od języka programowania (pobaw się w C/C++ pechapianym serializerem czy pythonowymi picklami to będziesz wiedział o co chodzi).

Szczególnie w aplikacjach webowych JSON jest praktycznie jedynym używanym formatem z uwagi na to, że wbudowane mechanizmy przeglądarek wzbogacone przez JQuery/AJAX pozwalają na bardzo prostą implementację przy minimalnej znajomości JavaScriptu. Coś w stylu:

$.post({
	'url': 'http:/192.168.1.10/ustaw_diody',
	'dataType': 'text',
	'data': {
		'diody': [23,24,25,40,50],
		'kolor': [255,255,0],
		},
	success: function(a) {alert(a);},
	error: function(a,b,c) {alert(a+' '+c);}
})

A bardziej życiowo (fragment):

'kolor': [
    $('#redslider').val(),
    $('#greenslider').val(),
    $('#blueslider').val()]

Oczywiście JSON ma swoje wady: pełny deserializer wymaga dość dużo pamięci, co w przypadku ograniczonej wielkości RAM w mikrokontrolerach może być trudne do uzyskania. Ale z drugiej strony istnieją uproszczone deserializery, umozliwiające korzystanie z tej notacji nawet na małym Arduino.

Reasumując: znać trzeba, natomiast wybór formatu przesylania danych powinien należeć do autora systemu (nie: aplikacji). To może być JSON, XML, urlencode czy nawet w przypadku prostego polecenia tekst typu "polecenie parametr". Możliwości jest wiele, ale trzeba je znać aby wybrać najlepszą w konkretnej sytuacji.

[_LM_]

Jeśli zestawiam połączenie klient serwer to czy serwer może wymusić formatowanie danych? Np: serwer oczekuje danych z czujników w xml lub JSON? 

Edytowano Grudzień 27, 2023 przez _LM_

[ethanak]

No ale to zależy od konkretnej aplikacji. Aplikacji obowiązkiem jest wysłanie danych do serwera w formacie dla niego zrozumiałym. Część aplikacji serwerowych rozumie więcej niż jeden format (np. urlencode i JSON, albo xml i JSON).

W niektórych aplikacjach typu REST można wymusić a serwerze sposób serializacji (np. Fakturownia może zwracać dane w postaci JSON lub XML), ale to nie jest żaden standard. Zresztą - REST jest tylko opisem pewnych wymogów (np. bezstanowość połączenia), a nie mówi nic o formatach przesyłania danych.

Ergo: jeśli serwer oczekuje JSON-a to psim obowiązkiem aplikacji jest wiedzieć czego serwer oczekuje i w takiej postaci mu to wysłać. Na szczęście serializery są dużo prostsze niż deserializery, można pchać dane bezpośrednio na socket, czyli Arduino UNO powinno sobie z tym poradzić na wpół spiąco 🙂

 

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[H1M4W4R1]

1 godzinę temu, _LM_ napisał:

Jeśli zestawiam połączenie klient serwer to czy serwer może wymusić formatowanie danych? Np: serwer oczekuje danych z czujników w xml lub JSON? 

Od tego są nagłówki HTTP 😉 Serwer informuje aplikację czego oczekuje a aplikacja ma się dostosować. Tak samo aplikacja może poinformować serwer o swoich możliwościach w kwestii oczekiwanych danych.

[ethanak]

Przed chwilą, H1M4W4R1 napisał:

Od tego są nagłówki HTTP

A kto mówi o HTTP?

[H1M4W4R1]

Przed chwilą, ethanak napisał:

A kto mówi o HTTP?

A kto jest tak nienormalny, że używa czegoś innego do robienia REST API?

[_LM_]

Ok w między czasie zacząłem trochę uzupełniać wiadomości, tu zostawię krótki film. Chwilowo nie mam więcej pytań 

 

[ethanak]

6 minut temu, H1M4W4R1 napisał:

A kto jest tak nienormalny, że używa czegoś innego do robienia REST API?

A gdzie w opisie REST jest mowa o tym, że transportem musi być HTTP? Jest tylko o bezstanowości. Poza tym jest tu mowa o IoT i przesyłaniu danych między urządzeniami - a do tego REST nie jest raczej potrzebny.

Edytowano Grudzień 27, 2023 przez ethanak