API'yi deneyin ve yayımlayın

API dosyasının kaydedilmesi, çalışan projenin yenilenmesi ve Git’teki sürümün deployment’a alınması ayrı adımlardır. Bu sayfa hangi çağrının hangi sürüme gittiğini kontrol ederek ilerlemenizi sağlar.

Commit, imaj ve ayrı üretim ortamına sürüm taşıma adımlarını geliştirmeden üretime rehberiyle birlikte izleyin. Bu sayfa API’nin erişim ve test tarafını tamamlar.

Hangi deneme hangi soruyu yanıtlar?

Bu üç denemenin sonuçlarını birbirinin yerine kullanmayın. Örneğin response örneğinde total: 50 yazmak Mock’ta bu sonucu gösterebilir; gerçek hesaplamayı sipariş örneğindeki route yapar. Dış erişim kapalıyken geliştirici Running project ile çağrı yapabilir.

Exposure kapalıyken Publication → Unpublished / Serving → Stopped görünmesi, geliştirme runtime’ının da kapalı olduğu anlamına gelmez. Publication dışarıya sunulan hedefi anlatır; geliştirme çağrısı için proje başlığındaki duruma ve Try it → Running project durumuna bakın.

Çalışma sırası

Mock ile sözleşmeyi inceleyin

1. API design içinde bir operation seçin ve Try it sekmesini açın.
2. Target → Mock seçin.
3. Gerekli parametreleri, varsa Request content type, Request body ve Response content type (Accept) değerlerini doldurun.
4. Send seçin.

Mock, işlemdeki başarı yanıtlarından birini ve onun örneğini veya schema’dan üretilen gövdeyi kullanır. Eksik zorunlu girdileri gösterebilir; tam runtime schema doğrulamasının, iş mantığının veya bağlantı testinin yerine geçmez. Beklenen sözleşmeyi ekip içinde konuşmak ve örnek hazırlamak için kullanın.

Gerçek geliştirme çağrısını gönderin

1. API’de Save, route ve properties dosyalarında Saved durumunu doğrulayın.
2. Proje başlığından Run seçin. Zaten çalışıyorsa Reload kullanın.
3. Hazırlık hatası varsa belirtilen Direct girişini, sözleşmeyi veya erişim kaynağını düzeltin.
4. Try it → Target → Running project seçin. Gerekirse Refresh runtime status ile durumu yenileyin.
5. Send seçip gerçek HTTP durum kodu, içerik türü, süre ve gövdeyi inceleyin.

Bu istek gerçek iş mantığını çalıştırır. Kuyruğa yazma, kayıt oluşturma veya bağlı sisteme çağrı gibi etkileri olabilir; test verisi kullanın. Cancel, bekleyen tarayıcı isteğini durdurur; route’un daha önce yaptığı işi geri almaz.

Kaydedilmemiş API değişiklikleri çalışan projeye dahil değildir. Yeni operation görünmüyor veya eski schema uygulanıyorsa önce Save, sonra Reload yapın. Running project denemesinde istek gövdesi UTF-8 olarak en fazla 1 MiB, alınan yanıt gövdesi de en fazla 1 MiB olabilir. Daha büyük girdiler veya sonuçlar için uygun HTTP istemcisi kullanın; Test request body exceeds 1 MiB. hatasında deneme girdisini küçültün.

Public adresi hazırlayın

Ortam yöneticiniz gateway’i, dışarıdan erişilen adresi ve seçilen transport’u hazırlamalıdır. HTTPS için adrese uygun güvenilir sertifika gerekir. API access adresi ortamın public URL ayarından gelir; yanlış host veya protokol görünüyorsa bunu proje path’ini değiştirerek çözmeyin.

1. API access → API exposure → Enabled seçin.
2. Public transport seçin ve Access policy ayarını tamamlayın.
3. Save seçin.
4. Geliştirmede erişimi uygulamak için Run/Reload yapın.
5. Publication bölümünde Refresh publication status kullanın. Ready durumunu ve Serving bilgisini kontrol edin.
6. İşlemin yanındaki Copy operation address ile tam adresi alın.

Adres şu parçalardan oluşur:

https://lunex.example.com/<projectId><server-base-path><operation-path>

Örneğin proje orders-api, server /api, operation GET /orders/{orderId} ise ORD-1001 için çağrı adresi:

https://lunex.example.com/orders-api/api/orders/ORD-1001

Projenin görünen adını veya route dosya adını değiştirmek bu ön eki değiştirmez. Başka proje kimliğiyle oluşturulan kopyanın adresi de farklıdır. Yalnızca sözleşmede tanımlı yöntem ve yollar yayımlanır.

Tek adresin aktif hedefini bilin

Bir ortamda projenin tek public adresi vardır. Run/Reload, erişim etkinse bu adresi geliştirme runtime’ına yönlendirir; o adrese gelen diğer istemciler de geliştirme sürümüne ulaşır.

Geliştirme runtime’ı durdurulduğunda son başarılı deployment varsa adres ona döner; yoksa proje API’si dış erişimden kaldırılır. Başarılı Build/deployment sonrası adres deployment’a yönelir. Canlı kullanıcıların geliştirme işlemlerinden etkilenmemesi için üretim ve geliştirme ortamlarının adreslerini ayrı kullanın.

Save veya Refresh publication status tek başına hedefi değiştirmez. Ekrandaki değişikliğin canlıya uygulanıp uygulanmadığını Serving ve durumdan okuyun.

Bir değişiklik üzerinden izleyin

Deployment’ın önceki sözleşmeyi çalıştırdığını, sizin çalışma alanında quantity minimum değerini değiştirdiğinizi varsayın:

1. Save sonrasında dosya yeni kuralı içerir; mevcut deployment değişmez.
2. Run/Reload sonrasında geliştirme runtime’ı yeni kuralı kullanır. Exposure etkinse ortak public adres de geliştirme hedefini seçer; aynı adrese gelen diğer istemciler yeni kuralla karşılaşır.
3. Değişiklik Git’e alınıp Build başarılı olduğunda deployment yeni kaynağı çalıştırır ve public hedef deployment olur.
4. Build yapılmadan geliştirme runtime’ını sonlandırırsanız önceki başarılı deployment yeniden servis verebilir; onun eski kuralı da geri gelir. Kubernetes ortamında geliştirmeyi sonlandıran Delete container, proje dosyalarını silmez.

Bu yüzden “dosya kaydedildi”, “geliştirmede denendi” ve “deployment’a alındı” bilgilerini ayrı izleyin. Ortak adresi kullanan ekiplerin test ve üretim ortamlarını bilmesi gerekir.

Kalıcı deployment oluşturun

1. Sözleşmeyi, tüm Direct route’larını, properties ve api-publishing.yaml dosyasını kaydedin.
2. Source → Files üzerinden farkları inceleyin. Değişikliklere ait bütün gerekli dosyaları seçerek Commit and push yapın.
3. Projenin son commit’inin yayımlamak istediğiniz değişiklikleri içerdiğini doğrulayın. Build bölümünde Build seçin. İmaj, derlenen commit’in kısa kimliğiyle otomatik etiketlenir.
4. Build loglarını ve deployment durumunu izleyin. İstek anında sabitlenen son Git commit’i derlenir; çalışma alanındaki daha yeni kaydedilmemiş veya commit edilmemiş dosyalar bu deployment’a girmez.
5. API access durumunu yenileyin. Ready ve beklenen Serving hedefini kontrol edin.
6. Public adresi gerçek istemciyle çağırın; başarı, hatalı veri ve erişim reddi senaryolarını doğrulayın.

Bir build isteğinin kabul edilmesi hazır olunduğu anlamına gelmez. Build completed, Deployment rollout’u ve erişim kaynakları tamamlandığında görünür. Ayrıntılı akış için Git ve runtime/deployment sayfalarını kullanın.

Yayın sonrasında bir başarı çağrısı, bir hatalı veri çağrısı ve bir erişim reddi çağrısı yapın. HTTP durumunu ve gerçek gövdeyi sözleşmeyle karşılaştırın; response şeması otomatik doğrulanmadığı için alan türlerini de kontrol edin. Test çağrısı kayıt oluşturabiliyorsa örnek verinin iş sistemindeki etkisini hesaba katın.

API’yi dış erişimden kaldırın

1. API access → API exposure → Disabled seçip Save yapın.
2. Geliştirme hedefinde hemen uygulamak için Reload yapın.
3. Deployment’ta kalıcı olarak kaldırmak için değişikliği Git’e gönderip Build çalıştırın.
4. Publication durumunu ve gerçek adreste erişimin kapandığını kontrol edin.

Yalnızca dosyayı silmek veya Disabled seçimini kaydetmek mevcut deployment’ı değiştirmez. Geliştirmeyi durdurmak da başarılı bir deployment’ın API’sini kapatmaz; adres deployment’a dönebilir.

Durumları ve hataları okuyun

Sözleşmeyi paylaşmak için Source → Files içindeki openapi.json satırından Download source kullanın. Paylaşmadan önce örnekleri, açıklamaları ve özel alanları gerçek credential veya hassas veri içermemeleri için gözden geçirin. API tüketicisine dosyayla birlikte ortam adresini, erişim yöntemini ve örnek istekleri verin.

Yukarıdaki kontrollerle sorun çözülmezse API hata teşhisindeki sırayı izleyin. Dış çağrı başarısızken çalışan route’u veya şemayı değiştirmeden önce adres, Serving ve erişim katmanını ayırın.