Bir HTTP sunucusu ve istemcisi arasında bir arayüz paylaşmanın bir yolunu öğrendiğimde Spring Cloud Netflix belgelerini okuyordum . Genel HTTP iletişimine genişletilmemesinin bir nedeni olmamasına rağmen, bu örneği mikro hizmetler için kullanırlar:
// 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 {
}
Bu, hem sunucu (Bahar @RestControlleronu HTTP sunucusuna dönüştürür) hem de istemci (Feign @FeignClient, HTTP istemcisi kullanımı için ayarlar ) olarak kullanılan bir arabirimi tanımlar . Sunucu ve istemci sınıfı uygulamaları ayrı projelerde kullanılabilir, ancak türlerin eşleştiğinden emin olmak için aynı arabirimi kullanır.
Bununla birlikte, örneğin altına aşağıdaki uyarıyı koyuyorlar:
Not: Genellikle bir sunucu ile istemci arasında bir arayüz paylaşılması önerilmez. Sıkı bağlantı sağlar ve ayrıca Spring MVC ile şu anki haliyle çalışmaz (yöntem parametre eşlemesi kalıtsal değildir).
Tamam, bu yüzden şu anda iyi entegre değil ... ama bu bölüm, kodun paylaşılması ve sunucu ile istemci arasında daha önemli olduğunu düşündükleri bağlantıyı tanıtmaya yönelik uyarıdan sonra geliyor . Bir arayüzü bu şekilde paylaşmanın neden bu kadar kötü bir fikir olduğunu düşünüyorlar?
Bu olmadan, sunucu ve istemcinin birbirlerine anlayabilecekleri verileri göndermelerini garanti etme yeteneğini kaybedersiniz. Birine alan ekleyebilir ancak diğerini ekleyebilir ve yalnızca çalışma zamanına kadar uyumsuzluğu keşfedebilirsiniz. Benim fikrime göre, bu kuplajı tanıtmak değil , sadece zaten var olan kuplajı ortaya çıkarmaktır. Sunucuları tamamen bağımsız hale getirme ihtiyacı, ne tür veriler alacaklarını bildirme ihtiyacından daha mı fazla?