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

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

Her kuruluşun benzersiz bir yazılım geliştirme yaşam döngüsü (SDLC) vardır. API proxy dağıtımını şu anda başka uygulamaları geliştirmek, test etmek ve dağıtmak için kullandığınız işlemlerle senkronize etmek ve uyumlu hale getirmek genellikle gereklidir.

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 sağlar. RESTful API'nin yaygın bir kullanımı, diğer uygulamaları da dağıtan veya taşıyan daha büyük bir otomatik sürecin parçası olarak API proxy'lerini programatik olarak dağıtan veya API proxy'lerini bir ortamdan diğerine taşıyan komut dosyaları ya da kodlar yazmaktır. API Hizmetleri, SDLC'niz (veya başka birinin SDLC'si) hakkında hiçbir varsayımda bulunmaz. Bunun yerine, API geliştirme yaşam döngünüzü otomatikleştirmek ve optimize etmek için geliştirme ekibiniz tarafından koordine edilebilecek atomik fonksiyonları kullanıma sunar.

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

Ortam

Apigee Edge'deki her kuruluş, API proxy'leri için kullanılabilen en az iki dağıtım ortamına sahiptir: "test" ve "üret". İki ortam arasındaki ayrım keyfidir. Her ortam, farklı bir ağ adresi (URL) grubuyla tanımlanır. Amacımız, API'nin harici geliştiricilere sunulmasından önce API proxy'leri oluşturabileceğiniz ve doğrulayabileceğiniz bir alan sağlamaktır.

API proxy geliştirme sürecini 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 çalışma zamanında uygulamalar tarafından erişilen API proxy'leri arasında trafik ayırabilirsiniz. Her ortam için kullanılabilir ağ adresleri, söz konusu ortamda kullanılabilir olan VirtualHosts kümesinde tanımlanır.

Giden, sunucu TLS/SSL her ortam için otomatik olarak etkinleştirilir. Her ortamda iki Sanal Ana Makine ö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 VirtualHosts'ı dinlemesi gerektiğini belirtirsiniz. Üretime tanıtırken 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'de dinleme yapar.

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

default VirtualHost yapılandırmasını ProxyEndpoint yapılandırmasından silerek, 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ünün ana menüsünden Ortamlar'ı seçerek bir ortamda hangi sanal ana makinelerin kullanılabildiğini görebilirsiniz.

Ortamlar, verileri ve kaynakların ayrılmasını da sağlar. Örneğin, test ve üretim ortamlarında yalnızca ilgili ortamda çalışan API proxy'leri tarafından erişilebilen farklı önbellekler oluşturabilirsiniz. Ayrıca, test ortamında verilen API anahtarları üretim ortamında geçerli değildir ve bunun tersi de geçerlidir.

API proxy'lerini ortamlara dağıtma

API proxy'si oluştururken hangi ortamda çalışacağınıza karar vermeniz gerekir. Üretimde yeni bir API proxy'si oluşturmayı seçebilirsiniz ancak API'yi hazır olmadan geliştiricilere sunabileceğiniz için bu önerilmemektedir. Genel olarak test içinde bir API proxy'si oluşturarak başlayın. Testten sonra prod sürümüne yükseltilir.

Daha fazla bilgi için Dağıtımı anlama sayfasını inceleyin.

Testte iteratif geliştirme

Bir API proxy'si üzerinde çalışırken API Hizmetleri, yapılandırmanızın yinelemelerini düzeltme olarak kaydeder. Bir API proxy'sini dağıtırken dağıtılacak belirli bir revizyonu 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ına izin vermek için bir düzeltmeyi üretime tanıtabilirsiniz. Aynı zamanda, testte birden fazla düzeltme üzerinde iterasyon yaparak özellikler ekleyebilir veya politikalarda ince ayar yapabilirsiniz. Ardından, hazır olduğunuzda yeni düzeltmeyi üretime dağıtarak ilgili ortamdaki mevcut düzeltmenin üzerine yazabilirsiniz. Bu yöntemi kullanarak, geliştiricilerin API'nizin canlı bir düzeltmesini her zaman kullanabilmesini sağlayabilirsiniz.

Üretime promosyon

Bir API proxy'si tam olarak uygulanıp test edildiğinde "prod" olarak yükseltilmeye hazırdır. Test edilen API proxy'sinin revizyonu, üretimde dağıtılan API proxy'sinin revizyonunun üzerine yazmak için kullanılır.

API Hizmetleri, API proxy'lerinin sorunsuz bir şekilde dağıtılmasını sağlayan ve dağıtım işlemi sırasında uygulamalar ile son kullanıcılar üzerindeki etkiyi en aza indiren özellikler sunar.

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ıza olanak tanır. Ancak birçok durumda güvenlik, güvenilirlik ve tutarlılıkla ilgili şartlar, geliştirme ekiplerinin dağıtım prosedürlerini komut dosyası olarak yazmasını zorunlu kılar. Bunu yapmak için API Hizmetleri tarafından sunulan RESTful API'yi çağıran kod ve komut dosyaları yazabilirsiniz.

Çevre kaynakları

Promosyon sırasında ek kontrol için yalnızca testteki API proxy'lerinde iterasyon yapmanız 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 kalacak şekilde yapılandırılmalarını sağlamanı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ında yük dengeleme bölümüne bakın.
• Önbellekler ve anahtar/değer eşlemeleri: Her iki kalıcı kaynak da ortama göre kapsamlandırılır. API proxy'lerinin, promosyon sırasında yapılandırma değişiklikleri gerektirmeden veri depolayabilmesi için adlandırma kurallarının kullanıldığından emin olmalısınız. Ortam önbelleği oluşturma ve düzenleme başlıklı makaleyi inceleyin.
• Hizmet Çağrıları hedefleri: Hizmet çağrıları, ortama bağlı olarak farklı hedefler kullanabilir (örneğin, test ortamındaki bir Hizmet Çağrısı bir demo hizmeti kullanıyorsa). Hizmet Açıklaması Politikası'na bakın.

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

Daha fazla bilgi için Dağıtımı anlama sayfasına bakın.