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

Devi configurare un server di prenotazione per consentire ad Actions Center di effettuare chiamate di ritorno per creare e aggiornare le prenotazioni per tuo conto.

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

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

Implementa un'interfaccia API REST

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

Per iniziare, configura un server di prenotazione per lo sviluppo o la sandbox che possa essere collegato all'ambiente sandbox di Actions Center. Passa a un ambiente di produzione solo dopo aver testato completamente il server sandbox.

Metodi

Per ogni tipo di server di prenotazione, è necessario un insieme diverso di metodi API. Facoltativamente, puoi scaricare la definizione del servizio in formato proto per iniziare a utilizzare l'implementazione dell'API. Le tabelle seguenti mostrano i metodi per ogni implementazione e includono i link ai formati proto del servizio.

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

Metodo	Richiesta HTTP
HealthCheck	GET /v3/HealthCheck/
BatchGetWaitEstimates	POST /v3/BatchGetWaitEstimates/
CreateWaitlistEntry	POST /v3/CreateWaitlistEntry/
GetWaitlistEntry	POST /v3/GetWaitlistEntry/
DeleteWaitlistEntry	POST /v3/DeleteWaitlistEntry/

Risorse API

Lista d'attesa

Per implementare la prenotazione in base alla lista d'attesa vengono utilizzate le seguenti risorse:

• WaitEstimate: una stima del tempo di attesa per un gruppo e un commerciante specifici.
• WaitlistEntry: voce di un utente nella lista d'attesa.

Flusso: crea una voce della lista d'attesa

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

Quando l'utente crea una voce nella lista d'attesa, Google ti invia il nome, il cognome, il numero di telefono e l'indirizzo email dell'utente. L'indirizzo email è lo stesso dell'Account Google dell'utente e viene trattato come un identificatore univoco. Dal tuo punto di vista, questa lista d'attesa deve essere considerata come un pagamento senza registrazione, perché Prenota con Google non può cercare l'account dell'utente nel tuo sistema. Assicurati che la voce della lista d'attesa finale sia identica a quella dei commercianti proveniente dal sistema della lista d'attesa.

Sicurezza e autenticazione

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

Tutte le richieste che Google invierà al tuo server di prenotazione verranno autenticate utilizzando l'autenticazione di base HTTP. Le credenziali di autenticazione di base (nome utente e password) per il server di prenotazione possono essere inserite nella pagina Configurazione server di prenotazione del Partner Portal. Le password devono essere ruotate ogni sei mesi.

Implementazioni di skeleton di esempio

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

• Skeleton Node.js js-maps-booking-rest-server-v3-skeleton
• Skeleton Java java-maps-booking-rest-server-v3-skeleton

Questi server hanno metodi REST simulati.

Requisiti

Errori HTTP ed errori di logica di business

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

• Errori relativi all'infrastruttura o a dati errati
  • Restituire questi errori al client con codici di errore HTTP standard. Consulta l'elenco completo dei codici di stato HTTP.
• Errori relativi alla logica di business
  • Restituire il codice di stato HTTP impostato su 200 OK e specificare l'errore della logica di business nel corpo della risposta. I tipi di errori di logica aziendale che puoi riscontrare sono diversi per i diversi tipi di implementazioni del server.

Per l'integrazione delle liste d'attesa delle prenotazioni, gli errori di logica di business vengono acquisiti in Waitlist Business Logic Failure e restituiti nella risposta HTTP. È possibile che si verifichino errori di logica di business quando viene creata 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 del gruppo del commerciante.
• MERCHANT_CLOSED viene utilizzato quando la lista d'attesa non è aperta perché il commerciante è già chiuso.

Identità

La comunicazione sulla rete non è sempre affidabile e Google potrebbe riprovare le richieste HTTP se non riceve risposta. Per questo motivo, tutti i metodi che modificano lo stato devono essere idempotenti:

• CreateWaitlistEntry
• DeleteWaitlistEntry

Per ogni messaggio di richiesta, ad eccezione di DeleteWaitlistEntry, vengono inclusi token di iridemicità per identificare in modo univoco la richiesta. In questo modo puoi distinguere tra una chiamata REST ripetuta, con l'intento di creare una singola richiesta, e due richieste distinte. DeleteWaitlistEntry è identificato in modo univoco dai rispettivi ID voce della lista d'attesa, pertanto nelle richieste non è incluso alcun token di idempotency.

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

• Una risposta HTTP CreateWaitlistEntry corretta include l'ID 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 alcuna seconda voce nella 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 tuo backend dovrebbe riprovare.

Il requisito di idempotenticità si applica a tutti i metodi che modificano lo stato.