Mikro hizmet API’leri ve anlaşmaları oluşturma, geliştirme ve sürüm oluşturma

  • Makale

İpucu

Bu içerik, .NET Docs'ta veya çevrimdışı olarak okunabilen ücretsiz indirilebilir bir PDF olarak sağlanan Kapsayıcılı .NET Uygulamaları için .NET Mikro Hizmet Mimarisi e-Kitabı'ndan bir alıntıdır.

PDF'i indirin

.NET Microservices Architecture for Containerized .NET Applications eBook cover thumbnail.

Mikro hizmet API'si, hizmetle istemcileri arasındaki bir sözleşmedir. Mikro hizmeti yalnızca API sözleşmesini bozmazsanız bağımsız olarak geliştirebilirsiniz. Bu nedenle sözleşme bu kadar önemlidir. Sözleşmeyi değiştirirseniz, bu durum istemci uygulamalarınızı veya API Gateway'inizi etkiler.

API tanımının yapısı, hangi protokolü kullandığınıza bağlıdır. Örneğin AMQP gibi bir mesajlaşma kullanıyorsanız, API ileti türlerinden oluşur. HTTP ve RESTful hizmetlerini kullanıyorsanız, API URL'lerden ve istek ve yanıt JSON biçimlerinden oluşur.

Ancak, ilk sözleşmeniz hakkında düşünceli olsanız bile hizmet API'lerinin zaman içinde değişmesi gerekir. Bu durumda ve özellikle DE API'niz birden çok istemci uygulaması tarafından kullanılan bir genel API ise, genellikle tüm istemcileri yeni API sözleşmenize yükseltmeye zorlayamazsınız. Genellikle hizmet sözleşmesinin hem eski hem de yeni sürümlerinin aynı anda çalıştığı şekilde hizmetin yeni sürümlerini artımlı olarak dağıtmanız gerekir. Bu nedenle, hizmet sürümü oluşturma için bir stratejinizin olması önemlidir.

API değişiklikleri küçük olduğunda , örneğin API'nize öznitelikler veya parametreler eklerseniz, eski bir API kullanan istemciler hizmetin yeni sürümüne geçmeli ve bu sürümle çalışmalıdır. Gerekli tüm eksik öznitelikler için varsayılan değerler sağlayabilirsiniz ve istemciler ek yanıt özniteliklerini yoksayabilir.

Ancak, bazen bir hizmet API'sinde önemli ve uyumsuz değişiklikler yapmanız gerekir. İstemci uygulamalarını veya hizmetlerini hemen yeni sürüme yükseltmeye zorlayamayabilirsiniz, çünkü bir hizmetin bir süre için API'nin eski sürümlerini desteklemesi gerekir. REST gibi HTTP tabanlı bir mekanizma kullanıyorsanız, bir yaklaşım API sürüm numarasını URL'ye veya bir HTTP üst bilgisine eklemektir. Ardından, hizmetin her iki sürümünü aynı hizmet örneğinde aynı anda uygulamak veya her biri API'nin bir sürümünü işleyen farklı örnekler dağıtmak arasında karar vekleyebilirsiniz. Bu işlev için iyi bir yaklaşım, farklı uygulama sürümlerini bağımsız işleyicilere ayırmak için Mediator düzenidir (örneğin, MediatR kitaplığı).

Son olarak REST mimarisi kullanıyorsanız Hypermedia, hizmetlerinizin sürümünü oluşturmak ve geliştirilebilir API'lere izin vermek için en iyi çözümdür.

Ek kaynaklar

Geriİleri