HTTP Client (WiFiS3)

Salve a tutti,
essendo la mia prima pubblicazione ne approfitto per presentarmi.
Mi chiamo Carlo e sono un appassionato di tecnologia.
Di recente ho iniziato un piccolo progetto che prevede l'utilizzo di Arduino (R4 Wifi) per la comunicazioni di dati verso un server remoto.
Vista l'occasione mi sono messo a lavorare ad una piccola libreria per semplificare le interazioni con servizi web.
Trattandosi di un argomento particolare ritenevo interessante condividere con la community il link alla repository (si tratta di un work-in-progress, ma potrebbe essere utile come spunto per qualcuno.. Chissà!) ma non conoscendo ancora le regole di questo forum ho pensato di chiedere prima la vostra opinione.
È possibile pubblicare una repository Github sul forum?
In caso come si può procedere?

Un grazie in anticipo,
un saluto a tutti!

Benvenuto,
la risposta è ... ovviamente SI ... metti il link in un post e magari spiega i vantaggi di questa tua libreria rispetto alle altre già esistenti :wink:

Guglielmo

Ciao Guglielmo,
ti ringrazio molto!
Procederò come da indicazioni!

Ancora grazie,
un saluto,

Carlo.

Ciao a tutti,
Di recente ho iniziato a lavorare ad un piccolo progetto che prevede l'utilizzo di Arduino (R4 Wifi) per la comunicazione di dati con un server remoto via HTTP.

Con l'occasione mi sono messo a lavorare ad una piccola libreria (un wrapper su WiFiS3 per essere più corretti) per semplificare le interazioni con i servizi web.

Trattandosi di un argomento di tendenza ritengo interessante condividere parte del lavoro (e la storia di questo piccolo progetto) con la community.
Nonostante il progetto si trovi ancora in fase preliminare e quindi completamente work-in-progress sono sicuro che possa essere di spunto per qualcuno!

Link al progetto:
Ino-HTTP-Client

Un saluto a tutti!

Intanto grazie per aver condiviso il tuo codice. E' sempre bello quando qualcuno vuol dare il proprio contributo alla crescita della community!

Qualche consiglio/spunto di riflessione: perché non erediti la classe C++ WiFiClient tipica del framework Arduino ed aggiungi i metodi che hai implementato?

Non mi convince inoltre la struttura per passare gli argomenti alla funzione che esegue il POST, usarla a runtime con dati non costanti in questo modo diventa complesso e poco user friendly visto cha va riallocata la memoria per adattarla alla dimensione del dato di volta in volta (la maggior parte degli utenti Arduino, non ha idea di come fare).

Considerato che il target della tua libreria è Arduino Uno R4, secondo me ti puoi permettere serenamente di usare dei vettori C++ (che tra l'altro sono già inclusi nella libreria WiFiS3).

#include <vector>

@yami-no-karuro:

Il mio

NON voleva significare "apri un altra discussione sullo stesso argomento", ma bensì "continua in questa dando le varie informazioni" ... :wink:

Pertanto ... ho riunito le due discussioni in una sola. Buona continuazione.

Guglielmo

Buonasera a tutti,
innanzitutto vi ringrazio per i preziosissimi riscontri sia riguardo al codice sia riguardo al regolamento.

Tra un momento libero e l'altro sono già riuscito ad apportare alcune migliorie grazie ai feedback ricevuti da @cotestatnt.

Mi trovo in linea con l'idea di utilizzare l'ereditarietà per estendere le funzionalità di WiFiClient ed ho già iniziato ad allineare il codice di conseguenza.

Mi piacerebbe però approfondire il discorso sulla parametrizzazione della attuale funzione httpPost() e l'utilizzo della struttura PostParam.

In un contesto di scambio informazioni con un servizio remoto, lo schema e la natura dei dati trasmessi sono (e dovrebbero essere) sempre noti e ben definiti.
Sarà quindi sempre ammessa variazione in termini di valori, ma mai di struttura e tipo di dato.

L'approccio attuale spinge il programmatore ad essere "cosciente" non solo riguardo al dato ma anche alla sua forma.
Al costo di rendere leggermente meno "amichevole" il wrapper si guadagna però maggior controllo.

Ho aggiornato anche le demo sulla Repository ma riporto un piccolo estratto qui di seguito.

void post_request_demo()
{
  int port = 80;
  char server[] = "arduino-demo.requestcatcher.com";
  if (!client.httpConnect(server, port))
    return;

  // Example...
  // Sending some sort of coordinates via latitude (lat) and longitude (log) parameters to the server.
  // Using 4 decimal to simulate ~10m GPS tolerance.

  srand(millis());

  float lat = rand_float(-90.0f, 90.0f);
  float lon = rand_float(-180.0f, 180.0f);

  char lat_str[XXS_BUFFER];
  snprintf(lat_str, sizeof(lat_str), "%.4f", lat);

  char lon_str[XXS_BUFFER];
  snprintf(lon_str, sizeof(lon_str), "%.4f", lon);

  PostParam params[] = {
    {"lat", lat_str},
    {"lon", lon_str}
  };

  char path[] = "/api/v1/coordinates";
  size_t num_params = sizeof(params) / sizeof(params[0]);
  client.httpPost(server, path, params, num_params);

  client.httpDisconnect();
}

Non essendo così ferrato nello specifico su C++ e su Arduino mi piacerebbe molto approfondire gli eventuali pro sull'utilizzo dei vettori in questo specifico caso.

Ringrazio tutti quanti in anticipo e vi auguro una buona serata.
Un saluto,

Carlo.

In linea di principio posso essere d'accordo, ma se stai cercando di sviluppare una libreria, non puoi prevedere qualsiasi caso d'uso possibile e quindi secondo me devi consentire all'utente di avere un certo grado flessibilità, scalabilità e perché no, anche semplicità d'uso (nel limite del possibile).

Ad esempio, se nella tua libreria pensi di supportare solo il Content-Type: application/x-www-form-urlencoded la struct è poco utile secondo me perché il "lavoro" necessario per preparare il payload è più complesso di quello che servirebbe per formattarlo in modo diretto con snprintf() o qualsiasi altro metodo di concatenazione stringhe :

key=value&key2=value2

Quindi in sostanza o lasci all'utente l'onere di preparare il payload da zero cosi da non limitarne il tipo utilizzabile (potresti aver bisogno di fare il POST di un JSON ad esempio che richiede un Content-Type diverso) o prevedi dei metodi per farlo in modo "guidato" ma che siano più flessibili (secondo me meglio la prima opzione, che poi è l'approccio usato in molte altre librerie simili).

Ciao @cotestatnt,
ti ringrazio molto per questo approfondimento e per lo scambio di opinioni.
Credo che effettivamente la giusta misura si trovi proprio nel lasciare al programmatore la responsabilità di formattare il contenuto utilizzando la strategia che preferisce.
Procederò sicuramente in quella direzione!

Ti ringrazio ancora e ti auguro una buona serata.
Alla prossima!

Un saluto,
Carlo.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.