Api RESTful: invia e-mail con collegamenti all'URL del client

Per una soluzione semplice che non richiede la modifica dei collegamenti nelle e-mail, è possibile che la parte pertinente dell'API risponda alle richieste degli agenti utente in un modo che abbia senso per un utente finale.

Chiedi all'API di rispondere alle richieste con un'intestazione accept contenente text/html reindirizzandole a una risorsa remota specificata dall'azienda. Consenti alle aziende di impostare il percorso di reindirizzamento (con una semplice sostituzione di token) attraverso un'altra parte dell'API.

Se la società non ha impostato un percorso di reindirizzamento, pubblica una pagina HTML contenente il contenuto dell'indagine anziché reindirizzare la richiesta.

Naturalmente, questo deve essere fatto solo per la parte dell'API che è collegata alle e-mail.

Questo approccio ha il vantaggio che le aziende sono in grado di modificare il percorso di reindirizzamento in qualsiasi momento e, se un cliente fa clic su un collegamento in una vecchia e-mail, verrà inviato alla nuova risorsa remota. Ciò ti consente anche di eseguire il tracciamento dei clic, se lo desideri.

Ecco un esempio di come potrebbe funzionare:

• Il tuo cliente "Business A" vuole mostrare richieste sul proprio cruscotto, quindi impostano un percorso di reindirizzamento effettuando una richiesta: PUT /v1/businesses/business_a/enquirypath , contenente {"path":"http://business_a.com/dashboard/enquiries/{id}"} .

• Il tuo cliente "Business B" non ha una propria dashboard, quindi non imposta un percorso di reindirizzamento.

• Invia email per conto delle aziende A e B. Le email si collegano alle stesse risorse utilizzate dall'API.

• Un utente finale fa clic sul link nell'email di Business B. Il server vede che viene richiesto il contenuto HTML (anziché JSON / XML). L'azienda B non ha indicato che le richieste dovrebbero essere reindirizzate, quindi l'API serve semplicemente la richiesta nel modulo HTML di facile utilizzo, come richiesto dall'agente utente.

• Un utente finale fa clic sul collegamento nell'e-mail da Business A. Il server vede che il contenuto HTML viene nuovamente richiesto. L'azienda A ha indicato che le richieste di richiesta devono essere reindirizzate al proprio server, pertanto l'API reindirizza la richiesta al percorso specificato.

Come viene generato enquiry_id nell'URL del client (che rimanda al sito di un partner)? Se corrisponde sempre all'ID di richiesta utilizzato per gli URL che controlli, puoi semplicemente richiedere che i partner forniscano un modello di URL da utilizzare quando si imposta un'integrazione con il proprio sistema. Quando generi l'email, utilizza il modello di URL fornito per generare l'URL del partner.

Al contrario, se l'URL è completamente generato dal partner, devi aggiungere un passaggio prima di inviare l'email : una chiamata all'API del partner per determinare l'URL.

In ogni caso, c'è un comportamento necessario sia dalla tua applicazione che dall'applicazione del partner: devono fornire un modo per generare un URL per te stesso (nel qual caso hai la responsabilità di generare l'URL e inviarlo) , o devono fornire un modo per chiedere a loro di generare un URL (nel qual caso si assume la responsabilità per la chiamata API e l'inserimento dell'URL nell'e-mail).

Questo è uno scenario di integrazione molto tipico, tra l'altro.

Puoi anche considerare se la generazione di URL è diversa per ogni partner. Se hai una partnership con quattro società, due potrebbero utilizzare un modello di URL standard mentre le altre due richiedono integrazioni personalizzate per determinare un URL. A livello di architettura, ciò significa che è necessario adattare la flessibilità in questo sottosistema:

1. È ora di inviare un'email.
2. Quale partner utilizza questa email?
3. Come faccio a generare un URL per questo partner?
4. Genera l'URL.
5. Includi l'URL nell'email.
6. Invia l'email.

Un approccio comune a questo sarebbe avere un URLGeneratorFactory che restituisce una classe che implementa l'interfaccia URLGenerator ; l'identità del partner determina quale specifica implementazione viene utilizzata.

Ho scritto un esempio per chiarire questa risposta.

Termini:

USER = end user of your client
CLIENT = your client
API = your server

I tuoi URL di esempio:

POST /v1/public/{business_name}/enquiries GET /v1/businesses/{business_name}/enquiries/{enquiry_id}

Non eseguire il controllo degli accessi nei tuoi url. Un URL di risorsa uno è più semplice da comprendere per i tuoi clienti.

Inoltre:

A client can call the following REST api URI to allow an unauthenticated user

Il fatto che l'utente finale non sia autenticato non significa che il client non sia autenticato.

Quindi diciamo che la tua richiesta verrà pubblicata:

USER sends post to: client.com/some/custom/path/enquiries
CLIENT receives the post post
CLIENT authenticates to the API
CLIENT sends post data to your API
  OR CLIENT sends post data + path to your API (path could be: client.com/some/custom/path/enqueries/{id} as an url template)
API receives the post
  IF no url is supplied lookup the client url in the database)
API inserts in database
API returns to CLIENT: {success: 1, url: 'http://api.com/enquiries/123'}
  OR API returns to CLIENT: {success: 1, url: 'http://api.com/enquiries/123', clientUrl: 'http://client.com/enqueries/123'}
CLIENT RECEIVES the response
CLIENT sends response back to USER ("Thanks for your enquiry" OR "You did not fill out a required field")
API adds e-mail to the queue, it knows the url from the post OR from the settings in the database for this client. 

In questo modo puoi personalizzare ulteriormente le e-mail perché possono contenere un logo, un nome commerciale del tuo cliente ecc.

EDIT Bello vedere la domanda migliorata!

Dopo aver letto di nuovo la tua domanda qui ti sembra di rimanere bloccato:

One option would be to provide a client URL in the original POST request. Problem with this is that the client won't know the URL to use until after the POST, at which point the email has already been added to the queue.

Ho pensato che forse avrebbe bisogno di ulteriori chiarimenti.

La prima regola nel tuo caso aziendale è:

Si desidera inviare un collegamento via e-mail al dominio del cliente. Solo il client conosce il dominio.

Questo richiede esplicitamente al client che l'API conosca il dominio, altrimenti non può eseguire l'azione di invio e-mail. D'accordo?

Non sono sicuro che tu sia conosciuto con i modelli di URL, un esempio è questo:

https://client.com/some/custom/path/enqueries/{id}

Esempio: link

Quindi il client non ti fornisce l'URL completo ma un modello che analizzi nella tua API. Accetti in anticipo le variabili che possono essere utilizzate.

Ciò significa che hai 2 opzioni:

1. Il cliente ti invia il dominio in anticipo. Ad esempio nei momenti:

   • Quando il cliente si iscrive al servizio API Puoi farlo tramite il modulo di registrazione o il pannello di configurazione, ad esempio.
   • Quando il client esegue l'accesso
   • Solo in una richiesta separata

2. Il cliente ti invia il dominio con la richiesta.

   JSON { urlTemplate: 'https://client.com/some/custom/path/enqueries/{id}', enquery: { name: 'test', } }

Devi accettare che il cliente abbia bisogno di comunicarti l'url se è personalizzato. Non puoi trovarlo magicamente.

Hai più opzioni per riceverlo, basta selezionare ciò che è meglio per te.