Perché è una cattiva idea condividere un'interfaccia tra server e client?

Stavo leggendo la documentazione di Spring Cloud Netflix quando ho scoperto un modo per condividere un'interfaccia tra un server HTTP e il suo client. Usano questo esempio per i microservizi, anche se non c'è motivo per cui non possa estendersi alla comunicazione HTTP generica:

// The shared interface, in a common library
public interface UserService {
    @RequestMapping(method = GET, value = "/users/{id}")
    User getUser(@PathVariable long id);
}

// The controller, on the server
@RestController
public class UserResource implements UserService {
}

// The same interface used for the client
@FeignClient("users")
public interface UserClient extends UserService {
}

Questo definisce un'interfaccia che viene utilizzata sia come server (The Spring lo @RestControllertrasforma in un server HTTP) sia come client (The Feign @FeignClientlo configura per l'uso del client HTTP). Le implementazioni della classe client e server possono essere utilizzate in progetti separati ma utilizzano comunque la stessa interfaccia per garantire che i tipi corrispondano.

Tuttavia, sotto l'esempio hanno messo il seguente avvertimento:

Nota: in genere non è consigliabile condividere un'interfaccia tra un server e un client. Presenta un accoppiamento stretto e in realtà non funziona con Spring MVC nella sua forma attuale (la mappatura dei parametri del metodo non viene ereditata).

OK, quindi non è ben integrato in questo momento ... ma quella parte viene dopo l'avvertimento contro la condivisione del codice e l'introduzione dell'accoppiamento tra il server e il client, che ritengono sia più importante. Perché pensano che sia una cattiva idea condividere un'interfaccia in questo modo?

Senza di essa, si perde la capacità di garantire che il server e il client si scambino reciprocamente dati comprensibili a entrambi. È possibile aggiungere un campo a uno ma non all'altro e scoprire solo la mancata corrispondenza fino al runtime. A mio avviso, non si tratta di introdurre un accoppiamento, ma semplicemente di rivelare un accoppiamento già esistente. La necessità di rendere i server completamente indipendenti è maggiore della necessità di far loro sapere quali tipi di dati riceveranno?

Il motivo, come indicato nei commenti, è che si traduce in un accoppiamento stretto tra la piattaforma client e la piattaforma server. In questo caso, ciò significa che al cliente è richiesto di utilizzare la lingua / piattaforma che si sta utilizzando sul server per comprendere il contratto previsto del server. Si noti che esiste una differenza tra la condivisione dello stesso codice (un artefatto di una lingua / piattaforma specifica) e l'accordo su un contratto specifico.

Molti progetti utilizzano invece la documentazione per i loro contratti. Richieste e risposte di esempio in un formato neutro (ad es. JSON) su protocolli standard (ad es. REST). (Vedi Documenti API Stripe , per esempio). Perché non è pratico scrivere un contratto basato su codice per ogni possibile piattaforma client che potresti voler utilizzare o consentire. Altri ancora usano strumenti di gestione API per definire contratti neutrali .

Il tuo esempio di aggiunta di un campo è una preoccupazione separata, un esempio del perché è importante per i contratti API versione. Consentire ai client di utilizzare la versione per cui sono progettati. Una nuova versione API incompatibile con le versioni precedenti esiste accanto alla vecchia. Il client per la versione precedente continua a funzionare fino a quando il suo team non riesce ad aggiornarlo o fino a quando non si ritira la versione precedente (dopo un periodo di deprecazione / migrazione). Vedi Modifica parallela .

Seguire l'avvertimento (avviso implicito nel) aiuta il client e il server a evolversi in modi e ritmi che hanno senso per ciascuno. Se puoi ragionevolmente garantire che il tuo server e client condivideranno sempre la stessa lingua / piattaforma E si evolveranno allo stesso ritmo, allora usando un artefatto di codice specifico per la lingua e la piattaforma, il tuo contratto probabilmente andrà bene. Tuttavia, questa probabilmente non è un'aspettativa ragionevole, soprattutto per i progetti destinati a Netflix OSS (qualcosa specificamente orientato alla scalabilità e alle prestazioni del cloud, con tutta la complessità necessaria).