marcomattei ha scritto:
vorrei che mentre crea i posti controlli anche quali sono occupati e poi gli applicherei una classe per colorarli di rosso ad esempio
La situazione dei posti dovresti averla all'interno di un array o una matrice, con (ipotizzo) un valore diverso in base allo stato del singolo posto, come detto già in un precedente post, ad esempio "occupato", "libero", ecc.
Presumo che questa struttura venga aggiornata nel momento in cui si ricevono dal database le informazioni relativo allo stato attuale dei posti.
Per identificare lo stato del singolo posto, in fase di creazione del pulsante relativo basta controllare nella struttura dati qual è il valore presente nella cella che corrisponde a quel posto, in modo da assegnare la classe CSS specifica, che ne regola la visualizzazione corretta.
Come aggiungere una classe a un elemento te l'ho già indicato in una risposta precedente.
Il codice che hai postato mi risulta poco leggibile e un pochino farraginoso: io tenderei a separare il più possibile la parte logica (es. struttura dati con lo stato dei posti, funzioni che agiscono su tali posti per cambiarne lo stato, funzioni che recuperano lo stato dalla struttura, ecc.) dalla parte della UI, ossia quella delle funzioni che prendono lo stato attuale dei posti e la riversano sugli elementi della pagina tramite assegnazione di classi CSS opportune, le quali devono essere definite in un file CSS separato dove viene indicato, per ogni stato possibile del posto, come questo deve apparire (colore di sfondo, eventuale immagine, ecc.).
Le due parti, logica e UI, devono parlarsi a vicenda chiamando l'una metodi dell'altra quando l'utente fa un clic, ad esempio, oppure quando qualcosa varia nella struttura dati a fronte di un cambiamento, proveniente dal DB remoto o dall'applicazione di un'azione da parte dell'utente (quindi una risposta a un evento) per poter aggiornare la rappresentazione. Riassumendo con un motto,
"Divide et impera".
Non saprei cosa altro aggiungere, poiché tu dici che la difficoltà è "collegare le due parti", una affermazione che in pratica sottende lo sviluppo dell'intera soluzione: se hai una difficoltà specifica nell'uso di una API è un discorso, se invece è necessario scrivere tutto il codice per far funzionare il sistema è un altro discorso.