Solitamente si tende a far confusione tra gli strumenti necessari allo sviluppo di un e-commerce e le nozioni che ne sono alla base.
Il carrello e l'ordine
Il protocollo HTTP è stateless, ossia non ha memoria. Quando si passa dalla pagina A alla pagina B non si ha mai una comunicazione tra le due pagine ma ciascuna di essa si comporta come un blocco a sé stante.
Il carrello ha invece bisogno di memoria e di comunicazione per poter funzionare: l'utente sceglie un prodotto, lo aggiunge al carrello e poi prosegue la navigazione sul sito.
Il concetto di base del carrello è la sessione, ossia un sistema di archiviazione temporaneo dei dati. PHP, JavaScript, Python ecc. dispongono tutti di API per creare e gestire le sessioni.
Il mezzo tecnico più comune per gestire una sessione sono i cookie: un cookie può memorizzare una certa quantità di dati sotto forma di stringa.
JavaScript sfrutta anche lo storage interno del browser quando viene utilizzato lato client. Questa scelta, che prende il nome di web storage, fa in modo di aggiungere una nuova implementazione a quelle basate sui cookie.
Quindi un carrello può essere pensato come una scatola in cui vengono posti gli oggetti creata all'interno della sessione.
Come al supermercato, il carrello si riempie o si svuota di prodotti e ha una destinazione obbligata: la cassa, anche se il web offre all'utente la possibilità di abbandonare il carrello lasciando il sito.
L'ordine non è altro che il carrello con l'aggiunta dei dati personali dell'utente (nome, cognome, dettagli del pagamento, ecc.) una volta che questi raggiunge la cassa (checkout).
Non è un caso se usando il paradigma ad oggetti (OOP) l'ordine e il carrello vengono rappresentati con due classi distinte ma in relazione tra loro.
L'ordine può avere diversi stati: pagato, annullato, in attesa di pagamento ecc. Gli stati assumono la forma di valori di una proprietà dell'oggetto nell'implementazione specifica.
I prodotti
A livello concettuale un prodotto non è altro che un oggetto con delle proprietà. Le proprietà variano a seconda del tipo di prodotto e a seconda di alcune variazioni che possono verificarsi in determinate condizioni.
Ad esempio il prezzo di un prodotto può variare nel caso di una promozione, dell'applicazione dello sconto o anche durante un intervallo di tempo (su Amazon il prezzo dei prodotti varia nel tempo seguendo le variazioni apportate dal rivenditore).
A livello di programmazione, un prodotto può essere rappresentato come una classe che deve essere istanziata per poter dare accesso alle sue proprietà. Dato che un prodotto viene identificato univocamente tramite un ID, l'istanziazione può essere implementata tramite questo parametro.
L'ID è ovviamente in relazione al database sottostante.
Le tassonomie
Le tassonomie sono collezioni/contenitori di prodotti. Una tassonomia può essere implementata in modo globale (categoria) o in modo particolare (tag).
Le tassonomie hanno una duplice natura: possono esseere dei macro oggetti a livello generale (aventi a loro volta delle proprietà) o divenire proprietà degli oggetti a cui vengono associate.
Il secondo caso trova un suo esempio tipico negli e-commerce basati sullo stack MEAN dove un prodotto ha in genere una proprietà che è un array contenente gli ID delle tassonomie di riferimento. Al contrario nello stack LAMP si userà un join su più tabelle basandosi sempre sull'ID delle tassonomie.
Le tassonomie solitamente hanno una struttura gerarchica basata sul rapporto tra genitore e discendenti.
Gli eventi
Un evento è una condizione che quando si verifica modifica temporaneamente lo stato esistente dell'e-commerce in relazione ai prodotti.
Durante una promozione, ad esempio, la home page può presentare in primo piano i prodotti in promozione. I prodotti a loro volta possono subire una variazione di prezzo con l'applicazione di uno sconto.
Tecnicamente, l'implementazione di un evento prevede un'interazionee diretta tra il backend e il frontend dell'e-commerce.
Nel backend viene definito l'evento e i prodotti che verranno modificati temporaneamente, nel frontend avverrà la modifica alla struttura HTML e alla presentazione CSS.
Un evento può essere rappresentato come una classe che avrà delle proprietà specifiche, come la data di inizio, la data di scadenza, una lista che conterrà prodotti o tassonomie e così via. Il codice dovrà tenere conto del fatto che un evento ha un solo stato con due valori distinti: attivo o non attivo.
Dato che ci possono essere più eventi, si dovrà creare una coda di eventi che si popolerà e spopolerà a seconda dello stato di ciascun evento.
La gestione degli eventi è tecnicamente l'aspetto più complesso di un e-commerce.
Il pagamento
Il pagamento può essere implementato in due modi:
- Online, con carta di credito o tramite PayPal
- Offline, ad esempio tramite bonifico bancario
Nel primo caso occorre scegliere un gateway di pagamento e utilizzare le API che tale gateway offre. È fondamentale studiare la struttura della risposta che il gateway restituisce dopo la transazione.
PayPal offre un'area di test (sandbox) per gli sviluppatori, ma va tenuto presente che tale area è quasi un esatto duplicato di quella ufficiale, quindi i dati forniti devono essere validi (ad esempio il numero di carta di credito deve soddisfare l'algoritmo di Luhn).
Nel secondo caso occorre attendere che l'utente abbia eseguito il pagamento, quindi l'ordine deve essere "ibernato" fino a quando non si riceve la notifica di avvenuto pagamento.
SSL
Un e-commerce teoricamente parlando dovrebbe essere interamente realizzato in SSL su HTTPS. Questa misura si rende necessaria per proteggere le transazioni in atto.
La sezione dedicata al pagamento (checkout) deve comunque utilizzare SSL anche quando l'elaborazione dei dati di pagamento fa affidamento ad un gateway esterno.
Il motivo è semplice: SSL prevede che entrambi gli endpoint della transazione siano protetti. Se non si utilizza SSL, il vostro endpoint diviene l'anello debole della catena. Inoltre alcuni gateway si rifiutano di elaborare la transazione se l'endpoint di partenza non è protetto da SSL.