Passaggio 3: implementa il server di prenotazione delle liste d'attesa

Devi creare un server di prenotazione per consentire al Centro azioni di effettuare richiamate per creare e aggiornare le prenotazioni per tuo conto.

• Implementazione delle liste d'attesa per le prenotazioni. Viene utilizzato quando partecipi al programma pilota Prenotazioni lista d'attesa. In questo modo il Centro azioni può recuperare le stime di attesa e creare voci della lista d'attesa per conto dell'utente.
• Implementazione standard. In questo modo il Centro azioni può creare appuntamenti e prenotazioni per conto dell'utente. Per implementare un server di prenotazione per l'integrazione end-to-end delle prenotazioni, consulta Implementare il server di prenotazione.

Consulta la documentazione del Portale partner per scoprire come configurare la connessione ai server di prenotazione della sandbox e della produzione.

Implementare un'interfaccia API REST

Implementare un'interfaccia API basata su REST. In questo modo Google può inviare richieste del server di prenotazione tramite HTTP.

Per iniziare, configura un server di prenotazione per lo sviluppo o la sandbox che possa essere connesso all'ambiente sandbox del Centro Azioni. Passa a un ambiente di produzione solo dopo aver completato il test del server sandbox.

Metodi

Per ogni tipo di server di prenotazione, devi disporre di un insieme diverso di metodi API. Facoltativamente, puoi scaricare la definizione del servizio in formato proto per iniziare l'implementazione dell'API. Le seguenti tabelle mostrano i metodi per ciascuna implementazione e includono link ai formati dei prototipi di servizi.

Implementazione della lista d'attesa
Definizione del servizio di lista d'attesa: Scarica il file di definizione del servizio proto.

Metodo	Richiesta HTTP
HealthCheck	OTTIENI /v3/HealthCheck/
BatchGetWaitEstimates	POST /v3/BatchGetwaitPrevents/
CreateWaitlistEntry	POST /v3/CreateAttendlistEntry/
GetWaitlistEntry	POST /v3/GetAttendlistEntry/
DeleteWaitlistEntry	POST /v3/DeleteAttendlistEntry/

Risorse API

Lista d'attesa

Per implementare la prenotazione basata sulla lista d'attesa vengono utilizzate le seguenti risorse:

• WaitEstimate: una stima di attesa per il numero di persone e il commerciante specifici.
• WaitlistEntry: la voce di un utente nella lista d'attesa.

Flusso: creazione di una voce della lista d'attesa

Questa sezione spiega come creare una prenotazione per l'integrazione delle liste d'attesa per le prenotazioni.

Figura 2: flusso di lavoro per la creazione di una voce di lista d'attesa

Quando l'utente crea una voce della lista d'attesa, Google ti invia nome, cognome, numero di telefono e indirizzo email dell'utente. L'email corrisponde all'Account Google dell'utente e viene considerata come un identificatore univoco. Dal tuo punto di vista, questa lista d'attesa deve essere considerata un pagamento senza registrazione, perché Prenota con Google non può cercare l'account dell'utente nel tuo sistema. Assicurati che l'ultima voce della lista d'attesa sia identica alle voci dei commercianti provenienti dal sistema della lista d'attesa.

Sicurezza e autenticazione

Tutte le comunicazioni con il tuo server di prenotazione avvengono tramite HTTPS, quindi è essenziale che il tuo server abbia un certificato TLS valido che corrisponda al suo nome DNS. Per configurare il server, ti consigliamo di utilizzare uno strumento di verifica SSL/TLS disponibile senza costi, come Qualys' SSL Server Test.

Tutte le richieste inviate da Google al tuo server di prenotazione saranno autenticate mediante l'autenticazione di base HTTP. Le credenziali di autenticazione di base (nome utente e password) del tuo server di prenotazione possono essere inserite nella pagina di configurazione del server di prenotazione all'interno del Portale partner. Le password devono essere ruotate ogni sei mesi.

Nota: devi impostare separatamente il nome utente e la password per Sandbox e Produzione utilizzando il selettore di ambienti.

Esempi di implementazioni di scheletri

Per iniziare, controlla i seguenti scheletri di esempio di un server di prenotazione scritto per i framework Node.js e Java:

• Struttura di Node.js js-maps-booking-rest-server-v3-skeleton
• Scheletro Java java-maps-booking-rest-server-v3-skeleton

Questi server hanno eliminato metodi REST.

Nota: per l'integrazione delle liste d'attesa per le prenotazioni, modifica i metodi REST impostandoli su quelli obbligatori per le liste d'attesa per le prenotazioni.

Requisiti

Errori HTTP ed errori della logica di business

Quando il backend gestisce le richieste HTTP, possono verificarsi due tipi di errori.

• Errori relativi all'infrastruttura o dati errati
  • Restituisci questi errori al client con i codici di errore HTTP standard. Consulta l'elenco completo dei codici di stato HTTP.
• Errori relativi alla logica di business
  • Restituisce il codice di stato HTTP impostato su 200 OK e specifica l'errore della logica di business nel corpo della risposta. I tipi di errori della logica di business che si possono verificare variano in base ai diversi tipi di implementazioni dei server.

Per l'integrazione delle liste d'attesa per le prenotazioni, gli errori della logica di business vengono acquisiti in Errore della logica di business della lista d'attesa e vengono restituiti nella risposta HTTP. Possono verificarsi errori della logica di business durante la creazione di una risorsa, ad esempio quando gestisci il metodo CreateWaitlistEntry. Tra gli esempi vi sono, a titolo esemplificativo:

• ABOVE_MAX_PARTY_SIZE viene utilizzato quando la voce della lista d'attesa richiesta supera il numero massimo di persone consentito dal commerciante.
• MERCHANT_CLOSED viene utilizzato quando la lista d'attesa non è aperta perché il commerciante è già chiuso.

Idempotenza

La comunicazione sulla rete non è sempre affidabile e Google potrebbe ritentare le richieste HTTP se non viene ricevuta alcuna risposta. Per questo motivo, tutti i metodi che cambiano stato devono essere idempotenti:

• CreateWaitlistEntry
• DeleteWaitlistEntry

Per ogni messaggio di richiesta tranne DeleteWaitlistEntry, vengono inclusi i token di idempotenza per identificare in modo univoco la richiesta. Ciò consente di distinguere tra una chiamata REST riprovata, con l'intento di creare una singola richiesta, e due richieste separate. DeleteWaitlistEntry è identificato in modo univoco rispettivamente dai rispettivi ID delle voci della lista d'attesa, quindi nelle richieste non è incluso alcun token di idempotenza.

Di seguito sono riportati alcuni esempi di come i server di prenotazione gestiscono l'idempotenza:

• Una risposta HTTP CreateWaitlistEntry riuscita include l'ID della voce della lista d'attesa creata. Se lo stesso CreateWaitlistEntryRequest viene ricevuto una seconda volta (con lo stesso idempotency_token), deve essere restituito lo stesso CreateWaitlistEntryResponse. Non viene creata una seconda voce della lista d'attesa e non viene restituito alcun errore.

  Tieni presente che se un tentativo di CreateWaitlistEntry non va a buon fine e la stessa richiesta viene inviata di nuovo, in questo caso il backend dovrebbe riprovare.

Il requisito di idempotenza si applica a tutti i metodi che cambiano stato.