API geliştirme yaşam döngüsü

Apigee Edge belgelerini görüntülüyorsunuz.
Apigee X belgelerine gidin. bilgi

Her kuruluşun benzersiz bir yazılım geliştirme yaşam döngüsü (SDLC) vardır. API proxy dağıtımını, diğer uygulamaları geliştirme, test etme ve dağıtma için kullandığınız süreçlerle senkronize etmeniz ve aynı hizaya getirmeniz genellikle gerekir.

API Hizmetleri, API proxy dağıtımını ve yönetimini kuruluşunuzun SDLC'sine entegre etmenizi sağlayan araçlar ve RESTful API'ler sunar. RESTful API'nin yaygın bir kullanımı, API proxy'lerini programatik olarak dağıtan veya API proxy'lerini bir ortamdan diğerine taşıyan komut dosyaları ya da kodlar yazmaktır. Bu, diğer uygulamaları da dağıtan veya taşıyan daha büyük bir otomatik sürecin parçasıdır. API Hizmetleri, SDLC'niz (veya bu konuda başka birinin) hakkında herhangi bir varsayımda bulunmaz. Bunun yerine, API geliştirme yaşam döngünüzü otomatikleştirip optimize etmek için geliştirme ekibiniz tarafından koordine edilebilecek atomik işlevleri kullanıma sunar.

API Hizmetleri API'leri, API Referansı'nda belgelenmiştir. API referansını kullanmaya başlama başlıklı makaleyi inceleyin.

Ortam

Apigee Edge'deki her kuruluşun, API proxy'leri için kullanılabilen en az iki dağıtım ortamı vardır: "test" ve "prod". İki ortam arasındaki ayrım rastgeledir. Her ortam yalnızca farklı bir ağ adresi grubu (URL) ile tanımlanır. Amaç, API harici geliştiricilere sunulmadan önce API proxy'lerini oluşturup doğrulayabileceğiniz bir alan sağlamaktır.

API proxy'si geliştirme işlemlerini SDLC'nizle senkronize etmek için bu ortamlardan yararlanabilirsiniz. Her ortam bir ağ adresiyle tanımlanır. Bu sayede, üzerinde çalıştığınız API proxy'leri ile uygulamalar tarafından çalışma zamanında erişilen API proxy'leri arasındaki trafiği ayırabilirsiniz. Her ortam için kullanılabilen ağ adresleri, o ortamda bulunan VirtualHosts kümesinde tanımlanır.

Gelen sunucu TLS/SSL, her ortam için otomatik olarak etkinleştirilir. Her ortamda iki VirtualHost önceden tanımlanmıştır: default ve secure. Varsayılan, bir HTTP adresini tanımlarken güvenli, önceden yapılandırılmış sunucu tarafı TLS/SSL ile bir HTTP/S adresini tanımlar. API proxy yapılandırmasında, ProxyEndpoint'in hangi VirtualHost'ları dinlemesi gerektiğini belirtirsiniz. Üretime yükseltirken genellikle API proxy yapılandırmasından default VirtualHost öğesini kaldırarak HTTP'yi devre dışı bırakırsınız.

Örneğin, aşağıdaki ProxyEndpoint, HTTP ve HTTPS üzerinden dinleme yapar.

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>default</VirtualHost>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

ProxyEndpoint yapılandırmasından default VirtualHost'u silerek yalnızca HTTPS'yi dinleyen, HTTP'yi dinlemeyen bir API proxy'si oluşturursunuz.

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

Yönetim kullanıcı arayüzü ana menüsünde Ortamlar'ı seçerek bir ortamda hangi VirtualHost'ların kullanılabildiğini görebilirsiniz.

Ortamlar, veri ve kaynakların ayrılmasını da sağlar. Örneğin, test ve üretim ortamlarında yalnızca o ortamda yürütülen API proxy'leri tarafından erişilebilen farklı önbellekler ayarlayabilirsiniz. Ayrıca, test ortamında verilen API anahtarları üretim ortamında, üretim ortamında verilenler ise test ortamında geçerli değildir.

API proxy'lerini ortamlara dağıtma

API proxy'si oluşturduğunuzda hangi ortamda çalışacağınıza karar vermeniz gerekir. Üretimde yeni bir API proxy'si oluşturmayı seçebilirsiniz ancak bu, API'yi hazır olmadan önce geliştiricilere sunabileceğiniz için önerilmez. Genel olarak, test içinde bir API proxy'si oluşturarak başlayın. Test ettikten sonra bu proxy'yi yükseltirsiniz prod.

Daha fazla bilgi için Dağıtımı anlama başlıklı makaleyi inceleyin.

Testte yinelemeli geliştirme

Bir API proxy'si üzerinde çalışırken API Hizmetleri, yapılandırmanızın yinelemelerini revizyon olarak kaydeder. Bir API proxy'si dağıttığınızda dağıtılacak belirli bir düzeltmeyi seçersiniz. Genellikle en son düzeltmeyi dağıtır ve gerekirse önceki düzeltme numarasına geri dönersiniz. Bu düzeltmelerin nereye dağıtılacağını seçebilirsiniz. Örneğin, geliştiricilerin API'nizle çalışmaya başlamasına izin vermek için üretimde bir revizyonu tanıtabilirsiniz. Aynı zamanda, test üzerinde birden fazla revizyon yineleyerek özellikler ekleyebilir veya politikaları ince ayarlayabilirsiniz. Ardından, hazır olduğunuzda yeni düzeltmeyi üretim ortamına dağıtabilir ve bu ortamdaki mevcut düzeltmenin üzerine yazabilirsiniz. Bu yöntemi kullanarak, geliştirme yaparken API'nizin canlı bir sürümünü her zaman geliştiricilerin kullanımına sunabilirsiniz.

Üretim sürümüne yükseltme

Bir API proxy'si tamamen uygulanıp test edildiğinde "prod"a yükseltilmeye hazır olur. Testteki API proxy'sinin düzeltmesi, üretimde dağıtılan API proxy'sinin düzeltmesinin üzerine yazmak için kullanılır.

API Hizmetleri, API proxy'lerinin sorunsuz bir şekilde dağıtılmasını sağlayan özellikler sunar. Bu sayede, dağıtım prosedürü sırasında uygulamalar ve son kullanıcılar üzerindeki etki en aza indirilir.

Komut dosyası dağıtımı

Apigee Edge yönetim kullanıcı arayüzü, API proxy'lerini doğrudan API proxy oluşturucudan üretime dağıtmanızı sağlar. Ancak birçok durumda güvenlik, güvenilirlik ve tutarlılıkla ilgili gereksinimler, geliştirme ekiplerinin dağıtım prosedürlerini komut dosyasıyla yapmasını zorunlu kılar. Bunu yapmak için API Hizmetleri tarafından kullanıma sunulan RESTful API'yi çağıran kodlar ve komut dosyaları yazabilirsiniz.

Çevre kaynakları

Promosyon sırasında ek kontrol için yalnızca testteki API proxy'lerini yinelemeniz ve üretimde dağıtılan API proxy'lerinde mümkün olduğunca az değişiklik yapmanız önerilir.

Bunu yapmak için her ortamla ilişkili belirli kaynakların, API proxy yapılandırmasında statik kalabilecek şekilde yapılandırıldığından emin olmanız gerekir.

• Hedef URL'ler: API proxy'lerinin test ve üretim sırasında farklı arka uç URL'lerini çağırması yaygın bir durumdur. Ortamdan bağımsız TargetEndpoint yapılandırmaları oluşturmak için TargetServer yapılandırmalarını kullanabilirsiniz. Arka uç sunucular arasında yük dengeleme başlıklı makaleyi inceleyin.
• Önbellekler ve anahtar/değer eşlemeleri: Her iki kalıcılık kaynağı da ortama göre kapsamlandırılır. API proxy'lerinin, tanıtım sırasında yapılandırma değişiklikleri gerektirmeden verileri depolamasını sağlamak için adlandırma kurallarının kullanıldığından emin olmanız gerekir. Ortam önbelleği oluşturma ve düzenleme başlıklı makaleyi inceleyin.
• ServiceCallout hedefleri: Hizmet çağrıları, ortama bağlı olarak farklı hedefler kullanabilir. Örneğin, test ortamındaki bir ServiceCallout, bir demo hizmetini kullanıyorsa. Hizmet açıklama metni politikasına bakın.

API proxy yapılandırmalarını ortamdan bağımsız hale getirmek için koşullu ifadeler de kullanabilirsiniz. environment.name değişkeniyle oluşturulan koşullu ifade, bir politika uygulanmadan veya arka uçta bir URL'ye yönlendirme yapılmadan önce mevcut ortamı değerlendirmek için kullanılabilir.

Daha fazla bilgi için Dağıtımı anlama başlıklı makaleyi inceleyin.