È buona pratica consumare sia l'API REST che SOAP per un particolare servizio?

Solo perché un'API è scritta usando SOAP non significa necessariamente che non può seguire i principi REST. Quindi è piuttosto difficile rispondere senza conoscere i dettagli specifici dell'API.

Se i principi REST sono rispettati nella progettazione dell'API SOAP, cambiare i tipi di contenuto dovrebbe essere piuttosto banale.

I principi più importanti qui da rispettare è il principio dell'apolidia. Se l'API è stateless, la semantica di ogni richiesta non dipende dallo stato della connessione, sarà possibile passare in modo sicuro tra diversi tipi di contenuto.

Esistono altri principi che renderebbero più facile combinare l'API SOAP e REST, ad esempio se l'API SOAP e REST identificava le risorse in un formato uniforme, vale a dire il principio dell'interfaccia uniforme. Questi sono superabili se non vengono seguiti, ma rendono i tipi di commutazione molto più semplici e meno complessi.

Avrai mai un'interazione diretta tra i dati ottenuti tramite l'API REST e l'API SOAP? In tal caso ti verrà chiesto di creare un codice di "traduzione" affinché possano essere interoperabili, il che potrebbe essere difficile o costoso.

Se non interagiscono mai direttamente direi di usare il REST quando puoi e fallback altrimenti.

Tieni presente che dovrai essere pronto ad eseguire l'upgrade quando le nuove funzionalità arrivano all'API REST.

Guarda la probabile roadmap futura per le API (che cosa è realisticamente probabile fare il venditore, non solo quello che dicono di aver pianificato). Se l'API SOAP verrà mantenuta almeno in condizioni uguali con l'API REST, l'utilizzo dell'API SOAP è un'opzione valida a lungo termine. Se, tuttavia, l'API SOAP rischia di raggiungere la fine del ciclo di vita e non essere mantenuta, con l'API REST avviata per la corrispondenza e tutte le nuove funzionalità si trovano solo nell'API REST, la soluzione consigliata è utilizzare l'API REST dove possibile e considera l'API SOAP come una riserva. In quest'ultimo caso, pianifica anche la migrazione dell'utilizzo dell'API SOAP sull'API REST a un certo punto per evitare di essere catturato inavvertitamente dalla rimozione dell'API SOAP da parte del fornitore.