Supporta formati di richieste multiple per il singolo endpoint REST

0

Sto creando un'API REST che espone un metodo di callback per un servizio di terze parti.

Immaginiamo che ci siano due servizi simili (ma non identici) di terze parti. Entrambi richiamano la mia API ( POST /api/callback ), ma hanno diversi formati di richiesta (JSON):

Provider 1

{"sender": "Provider1", "field1": "value1", "fieldN": "valueN"}

Provider 2

{"sender": "Provider2", "key1": "value1", "keyN": "valueN"}

Quindi hanno solo un parametro comune ( sender ) e altri potrebbero differire.

Successivamente, ho due DTO corrispondenti a cui JSON deve essere mappato

pseudo-codice:

class Provider1DTO {
    string sender;
    string field1;
    string fieldN;
}

class Provider2DTO {
    string sender;
    string key1;
    string keyN;
}

Provider1DTO dto1 = mapper.readJSON(json, Provider1DTO.class)
Provider2DTO dto2 = mapper.readJSON(json, Provider2DTO.class)

Domanda:

Qual è l'approccio corretto per raggiungere la personalizzazione per provider?

1) Introduci endpoint separati

/api/callback/provider1
/api/callback/provider2

2) Usa il singolo endpoint e analizza il campo sender del corpo della richiesta per mappare JSON al DTO pertinente

3) Usa singolo endpoint e analizza X-Sender-ID (esempio) di intestazioni di richiesta per mappare JSON al DTO pertinente

L'approccio 2 mi sembra il migliore, dal momento che non posso costringere i provider a utilizzare intestazioni di richieste personalizzate (come al punto # 3). Per quanto riguarda il n. 1: potrebbero esserci più servizi che forniscono un formato di richiesta identico, quindi non è necessario disporre di un endpoint separato

Che cosa pensi di questo? Grazie in anticipo

    
posta Nikolay Shevchenko 04.09.2018 - 11:52
fonte

2 risposte

1

C'è una ragione per cui i terzi devono inviare i loro dati in quel formato? Le API pubbliche richiedono la cooperazione tra fornitore e consumatore ed è prassi comune che l'accordo sia "Ti fornirò un'API che fa x, e ho bisogno che le richieste siano in formato y".

Approach #2 seems best to me, since I can't force providers to use custom request headers

Sono già stati "forzati" a inviare la richiesta a un endpoint personalizzato, con un corpo contenente presumibilmente valori personalizzati e specifici.

Se il consumatore dell'API che modifica le loro richieste è fuori questione (se ciò viene fatto senza la sua conoscenza / consenso), allora l'approccio # 2 / # 3 funzionerebbe. Raccomanderei di mappare il corpo della richiesta in una singola classe indipendente dal consumatore il più vicino possibile all'endpoint.

    
risposta data 04.09.2018 - 13:28
fonte
0

Il lavoro del tuo server è rappresentare una risorsa, identificata da un URI. Quella risorsa può avere rappresentazioni multiple (formati / serializzazioni). Hai una risorsa, due formati di richiesta (entrambi gli schemi JSON) che puoi accettare e due formati di risposta che puoi restituire (anche entrambi gli schemi JSON).

Mentre suggerisco che tutti i client che sono in grado di adattarsi staranno meglio adattandosi allo schema JSON più diffuso utilizzato (quindi in grado di parlare con altri server in futuro che già utilizzano questo formato), se ciò non può essere fatto, Raccomando di negoziare con l'intestazione HTTP Accept. Chiedi ai tuoi clienti di inviare lo schema con cui stanno richiedendo in un'intestazione Content-Type e lo schema che desiderano in un'intestazione Accept. Potrebbe essere necessario creare alcuni nuovi tipi di media per questo. Puoi crearne di privati o registrarli con IANA se pensi che dovrebbero diventare pubblici.

Entrambi i client devono inviare richieste a un singolo URL che non è chiamato ad es. "/ api / do-something", ma più simile a "/ type-of-thing / thing" - Gli URI dovrebbero essere nomi che dicono qual è la cosa che ottieni quando fai una richiesta GET. Mettere "api" nell'URL è un errore: tutti i siti Web sono API, indipendentemente dal fatto che il software client sia basato su computer o umano e indipendentemente dal fatto che stiano servendo file PDF o XHTML o immagini di gatti o JSON.

    
risposta data 08.09.2018 - 20:23
fonte

Leggi altre domande sui tag