{"id":426,"date":"2022-01-10T20:50:15","date_gmt":"2022-01-10T19:50:15","guid":{"rendered":"https:\/\/workerbase.org\/wordpress\/?p=426"},"modified":"2025-03-17T14:01:35","modified_gmt":"2025-03-17T13:01:35","slug":"http-e-web","status":"publish","type":"post","link":"https:\/\/arkenidar.com\/wordpress\/2022\/01\/10\/http-e-web\/","title":{"rendered":"HTTP e Web"},"content":{"rendered":"\n

Nelle web-app (applicazioni software costruite mediante tecnologie web e fruibili via web) ci sono due suddivisioni: client<\/em><\/strong> e server<\/em><\/strong>.<\/p>\n\n\n\n

Un client si connette al server. Nel caso web, quindi avendo un server HTTP, ci sono Richieste HTTP (HTTP Request) e Risposte HTTP (HTTP Response).<\/p>\n\n\n\n

Un utente mediante il client HTTP (ad esempio un web-browser come Mozilla Firefox o Google Chrome) effettua richieste HTTP che il server (backend) risponder\u00e0 con una risposta HTTP che il client HTTP elaborer\u00e0 (nel frontend, la parte vicina all’utente, ad esempio che gestisce l’aspetto grafico dell’interfaccia grafica utente di una web-app).<\/p>\n\n\n\n

Per gestire le richieste ci si serve ad esempio di un Controller, un componente software che risponde alle richieste all’interno della web-app lato server (back-end).<\/p>\n\n\n\n

Mi vengono in mente alcuni design pattern, ovvero modi riutilizzabili di strutturare i meccanismi software, modi ricorrenti e standardizzati conseguentemente.<\/p>\n\n\n\n

Il pattern Front Controller specifica che le richieste HTTP sono filtrate dal front controller che le gestisce, gestendo quindi un filtraggio dell’accesso alle risorse HTTP, ad esempio con blocchi in caso di mancata autorizzazione all’accesso, elaborazioni quali il templating HTML, che vedremo tra poco, e tutte le altre necessit\u00e0 che questa strutturazione software consente di risolvere (strutturazione architetturale).<\/p>\n\n\n\n

Il Templating HTML \u00e8 un modo di riusare del codice HTML, che per\u00f2 pu\u00f2 variare, avendo quindi parti prefissate e altre inserite all’occorrenza dinamicamente dal software.<\/strong> Il look appare consistente anche grazie a questo.<\/p>\n\n\n\n

Nel design pattern MVC (ModelloVistaControllore) il controllore gestisce le richieste HTTP (iniziate dal client e risposte dal server che le invia al client che le elabora). La vista \u00e8 un template HTML che viene dinamicizzato dal Modello contenente i dati del software da mostrare (inserendo tali dati nella vista\/template HTML).<\/p>\n\n\n\n

Il templating pu\u00f2 essere effettuato sia lato server sia lato client, anche mescolando gli approcci risolutivi nella stessa applicazione.<\/p>\n\n\n\n

Un templating lato server \u00e8 ottenibile quando il controllore passa i dati del modello alla vista come template HTML elaborato lato server. Al client arriva il template gi\u00e0 riempit<\/em>o con i dati<\/em>.<\/strong><\/p>\n\n\n\n

Un templating lato client HTTP \u00e8 ottenibile mediante una richiesta del modello al server, e una volta ricevuto il modello dal server esso riempir\u00e0 le parti dinamiche del template lato client (ad esempio un client HTML+JavaScript che mediante il JS genera l’ HTML dinamico servendosi dei dati del modello ottenuto mediante una apposita richiesta HTTP, stile AJAX\/REST). Il client riempe il template con i dati, presi i dati dal server (e dall’utente).<\/strong><\/em><\/p>\n\n\n\n

Quindi i template esistono sia nel client che nel server, seguendo un design di una architettura distribuita<\/strong><\/em>, in questo caso distribuita tra clients e servers (come potrebbe anche esserlo tra nodi di rete<\/em><\/strong> e peers vedasi PeerToPeer\/P2P).<\/p>\n","protected":false},"excerpt":{"rendered":"

Nelle web-app (applicazioni software costruite mediante tecnologie web e fruibili via web) ci sono due suddivisioni: client e server. Un client si connette al server. Nel caso web, quindi avendo un server HTTP, ci sono Richieste HTTP (HTTP Request) e Risposte HTTP (HTTP Response). Un utente mediante il client HTTP (ad esempio un web-browser come […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-426","post","type-post","status-publish","format-standard","hentry","category-senza-categoria"],"_links":{"self":[{"href":"https:\/\/arkenidar.com\/wordpress\/wp-json\/wp\/v2\/posts\/426","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/arkenidar.com\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/arkenidar.com\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/arkenidar.com\/wordpress\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/arkenidar.com\/wordpress\/wp-json\/wp\/v2\/comments?post=426"}],"version-history":[{"count":7,"href":"https:\/\/arkenidar.com\/wordpress\/wp-json\/wp\/v2\/posts\/426\/revisions"}],"predecessor-version":[{"id":439,"href":"https:\/\/arkenidar.com\/wordpress\/wp-json\/wp\/v2\/posts\/426\/revisions\/439"}],"wp:attachment":[{"href":"https:\/\/arkenidar.com\/wordpress\/wp-json\/wp\/v2\/media?parent=426"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/arkenidar.com\/wordpress\/wp-json\/wp\/v2\/categories?post=426"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/arkenidar.com\/wordpress\/wp-json\/wp\/v2\/tags?post=426"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}