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. Genellikle API proxy dağıtımını, şu anda diğer uygulamaları geliştirmek, test etmek ve dağıtmak için kullandığınız işlemlerle senkronize etmek ve uyumlu hale getirmek gerekir.

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

API Hizmetleri API'leri, API Referansı'nda açıklanmıştır. API referansını kullanmaya başlama bölümüne bakın.

API ortamlarına ve API geliştirme yaşam döngüsüne giriş için bu videoyu izleyin.

Ortam

Apigee Edge'deki her kuruluş, API proxy'leri için kullanılabilen en az iki dağıtım ortamına sahiptir: "test" ve "prod". İki ortam arasındaki fark rastgeledir. Her bir ortam farklı bir ağ adresi (URL'ler) grubuyla tanımlanır. Burada amaç, API harici geliştiricilere sunulmadan önce API proxy'leri oluşturup doğrulayabileceğiniz bir alan sağlamaktır.

SDLC'nizle işlenen API proxy'si geliştirme sürecini senkronize etmek için bu ortamlardan yararlanabilirsiniz. Her ortam bir ağ adresiyle tanımlanır. Böylece, üzerinde çalıştığınız API proxy'leri ile çalışma zamanında uygulamaların eriştiği proxy proxy'leri arasındaki trafiği ayırabilirsiniz. Her ortam için kullanılabilen ağ adresleri, söz konusu ortamda kullanılabilen 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 olarak bir HTTP adresi tanımlarken, güvenli olan bir HTTP/S adresi, sunucu tarafında önceden yapılandırılmış TLS/SSL ile tanımlanır. Bir API proxy yapılandırmasında, ProxyEndpoint'in hangi VirtualHost'ları dinlemesi gerektiğini belirtirsiniz. Üretime yükseltme yaparken genellikle API proxy yapılandırmasından default VirtualHost'u kaldırarak HTTP'yi devre dışı bırakırsınız.

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

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

ProxyEndpoint yapılandırmasından default VirtualHost'u sildiğinizde, HTTP'de değil yalnızca HTTPS'de dinleme yapan 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 mevcut olduğunu görebilirsiniz.

Ortamlar ayrıca veri ve kaynakların ayrıştırılmasını da sağlar. Örneğin, test ve üretim aşamasında farklı önbellekler oluşturabilirsiniz. Bunlara, yalnızca söz konusu ortamda çalışan API proxy'leri tarafından erişilebilir. Ayrıca, test ortamında yayınlanan API anahtarları üretim ortamında geçerli değildir ve bunun tersi de geçerlidir.

Ortamlara API proxy'leri dağıtma

API proxy'si oluşturduğunuzda hangi ortamda çalışacağınıza karar vermeniz gerekir. Üretim aşamasında yeni bir API proxy'si oluşturmayı seçebilirsiniz ancak bir API'yi hazır olmadan önce geliştiricilere sunabileceğiniz için bunu yapmanız önerilmez. Genel olarak test bölgesinde bir API proxy'si oluşturarak başlayın. Bunu test ettikten sonra prod platformuna yükseltebilirsiniz.

Daha fazla bilgi için Dağıtımı anlama bölümüne bakın.

Testte yinelemeli geliştirme

Bir API proxy'si üzerinde çalışırken API Hizmetleri, yapılandırmanızın yinelemelerini düzeltme olarak kaydeder. API proxy'si dağıtırken dağıtılacak belirli bir düzeltme seçersiniz. Genellikle en son düzeltmeyi dağıtır ve gerekirse önceki düzeltme numarasına geri dönersiniz. Bu düzeltmeleri nereye dağıtacağınızı seçebilirsiniz. Örneğin, geliştiricilerin API'nizle çalışmaya başlaması için bir düzeltmeyi üretime tanıtabilirsiniz. Aynı zamanda, testlerde birden fazla düzeltmeyi yineliyor olabilirsiniz. Test sırasında özellikler ekleyebilir veya politikalara ince ayarlar yapabilirsiniz. Ardından, hazır olduğunuzda bu ortamdaki mevcut düzeltmenin üzerine yazarak yeni düzeltmeyi üretime dağıtabilirsiniz. Bu yöntemi kullanarak, geliştirme sırasında her zaman API'nizin canlı bir düzeltmesini geliştiricilerin kullanımına sunabilirsiniz.

Üretime tanıtım

Bir API proxy'si tam olarak uygulandığında ve test edildiğinde "üretim"e yükseltilmeye hazırdır. 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 sunarak dağıtım prosedürü sırasında uygulamalar ve son kullanıcılar üzerindeki etkiyi en aza indirir.

Komut dosyası dağıtımı

Apigee Edge yönetim kullanıcı arayüzü, doğrudan API proxy oluşturucudan üretim yapmak için API proxy'leri dağıtmanızı sağlar. Ancak birçok durumda güvenlik, güvenilirlik ve tutarlılık gereksinimleri, geliştirme ekiplerinin dağıtım prosedürlerini komutlaması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.

Ortam kaynakları

Tanıtım sırasında daha fazla kontrol sahibi olmak için yalnızca testteki API proxy'lerini yinelemeniz ve üretimde dağıtılan API proxy'lerinde gereken kadar değişiklik yapmanız önerilir.

Bunu yapmak için her bir ortamla ilişkilendirilmiş 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 bölümüne bakın.
  • Önbellekler ve anahtar/değer eşlemeleri: Her iki kalıcılık kaynağı da ortama göre belirlenir. Tanıtım sırasında yapılandırma değişikliği yapmaya gerek kalmadan API proxy'lerinin veri 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 bölümüne bakın.
  • Hizmet Çağrısı hedefleri: Hizmet çağrıları, test ortamındaki bir Hizmet Çağrısı'nın demo hizmeti kullanması durumunda, ortama bağlı olarak farklı hedefler kullanabilir. Hizmet açıklama metni politikasını inceleyin.

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 politikayı uygulamadan önce veya arka uçtaki bir URL'ye yönlendirmeden önce mevcut ortamı değerlendirmek için kullanılabilir.

Daha fazla bilgi için Dağıtımı anlama başlıklı makaleye bakın.