API işbirliği eskiden ağır bir uygulama açmak, senkronize olmasını beklemek ve bir ekip arkadaşının ne değiştirdiğini görmek için paneller arasında tıklamak anlamına geliyordu. Bunların hiçbirine ihtiyacınız yok. Eğer API'niz bir OpenAPI dosyasıyla açıklanıyorsa, işbirliği çalışmalarının çoğu aslında metin işidir: spesifikasyonu versiyonlamak, bir farkı (diff) gözden geçirmek ve paylaşılan bir değişikliği birleştirmek. Bunların hepsi terminale sığar.
Bu kılavuz, bu üç işi halleden hafif CLI araçlarını kapsıyor. Buradaki her araç saniyeler içinde kurulur, tek bir komutla çalışır ve Git veya CI'a entegre olur. GUI yok, arka plan hizmeti yok, sadece bir değişiklik günlüğünü okumak için tüm ekip için kurulum gereksinimi yok. Ekip iş akışlarının daha eksiksiz bir resmi için API işbirliği araçları derlememizle başlayın; bu yazı terminal öncelikli bir alt kümedir.
Çerçeve şu. Komut satırından işbirliği, spesifikasyonun versiyonlanması (kimin hangi versiyona sahip olduğu), inceleme (ne değişti ve güvenli mi) ve paylaşılan değişiklikler (bir kişinin düzenlemelerini herkesin doğruluk kaynağıyla birleştirmek) olarak ayrılır. Aşağıdaki her araç bunlardan birini veya ikisini iyi yapar. OpenAPI spesifikasyonu, bu araçların okuyup yazdığı resmi standarttır, bu yüzden her şeyi çalıştıran ortak dildir. Yedi araç, her biri için gerçek bir kurulum ve örnek komut ve aralarından seçim yapabileceğiniz kısa bir tablo bulacaksınız.
Bir CLI aracını API işbirliği için “hafif” yapan nedir
Hafiflik bir his değil, gerçek bir ölçüttür. Bir araç, aşağıdakilerin çoğunu karşıladığında nitelikli sayılır:
- Küçük kurulum. Tek bir ikili, bir
npxçağrısı veya birnpm install -g. Kurulum aracı yok, çalışmaya devam edecek bir hizmet yok. - Hızlı başlangıç. Çalışır ve çıkar, böylece bir betik veya ön-taahhüt kancası içinde çağırabilirsiniz.
- Düşük yapılandırma. Sıfır veya minimum kurulumla düz bir OpenAPI dosyasına karşı çalışır.
openapi.yaml'ye işaretleyin ve başlayın. - Terminal öncelikli. Çıktı bir terminalde okunmak veya CI'a aktarılmak üzere tasarlanmıştır, bir web panelinde görüntülenmek için değil.
- Tek bir işi iyi yapar. Farkları bulma, yayınlama veya birleştirme; benimsemek zorunda olduğunuz bütün bir platform değil.
Araçlar kabaca en küçük ve en odaklıdan en entegreye doğru sıralanır. Son madde bir istisnadır: tek amaçlı bir ikili yerine tam bir proje CLI'dır ve versiyonlama, inceleme ve birleştirmeyi tek bir yerde kapsadığı için dahil edilmiştir.
Git + spesifikasyon dosyası (temel)
En hafif işbirliği aracı zaten sahip olduğunuzdur. OpenAPI dosyanızı kodun yanındaki depoya kaydettiğinizde, Git versiyonlamayı, geçmişi ve incelemeyi ücretsiz olarak halleder. `openapi.yaml`'e karşı yapılan bir çekme isteği, değişen tam satırları gösterir, ekip arkadaşları bu satırlar hakkında yorum yapar ve birleştirme paylaşılan değişikliktir. Git-yerel API işbirliğinin ardındaki tüm fikir budur.
# Track the spec in the repo, then review changes like any code
git add openapi.yaml
git commit -m "Add pagination params to GET /orders"
git diff main -- openapi.yaml
En iyisi: sıfır yeni araçla geçmiş ve inceleme. Her geliştirici bunu zaten biliyor.
Dürüst sınırlama: YAML üzerindeki ham Git farkları gürültülüdür. Yeniden sıralanmış bir anahtar veya yeniden girintilenmiş bir blok, API aynı olsa bile bir değişiklik gibi görünür. Sonraki araçların doldurduğu boşluk tam da budur: dosyanın metnini değil, API'nin anlamını karşılaştırırlar.
oasdiff
oasdiff, iki OpenAPI spesifikasyonunu karşılaştıran ve değişikliğin bozucu olup olmadığını söyleyen tek bir Go ikili dosyasıdır. Açık kaynaklıdır (Apache 2.0), yüzlerce farklı değişiklik türünü algılar ve çıkış kodu bir birleştirmeyi engellemeyi çok kolaylaştırır. CI'da çalıştırdığınızda, bozucu bir değişiklik, bir ekip arkadaşına ulaşmadan önce derlemeyi başarısız kılar.
# Install (macOS)
brew install oasdiff
# Fail the build if the new spec breaks existing clients
oasdiff breaking main-spec.yaml pr-spec.yaml
# exit 0 = safe, exit 1 = breaking changes found
Değişen her şeyin, bozucu olsun ya da olmasın, insan tarafından okunabilir bir özeti için `oasdiff changelog base.yaml revision.yaml` kullanın.
En iyisi: birleştirme kapısı olarak bozucu değişiklik tespiti. Hızlı, betiklenebilir, hesap gerekmez.
Dürüst sınırlama: farkları bulur ve raporlar; belgeleri yayınlamaz veya dalları yönetmez. İyi yapılmış keskin bir iş.
Optic
Optic, Git iş akışlarını göz önünde bulundurarak OpenAPI değişikliklerini karşılaştıran, lintleyen ve inceleyen npm ile yüklenen bir CLI'dır. MIT lisanslıdır ve `$ref`, `oneOf`, `allOf` ve basit farkları yanıltan diğer şema şekillerini anlar. oasdiff size geç/kal kapısı sunarken, Optic inceleme konuşmasına odaklanır: çalışma spesifikasyonunuzu ana dalınızdaki sürümle karşılaştırabilir ve bir PR için API düzeyindeki değişiklikleri özetleyebilir.
# Install
npm install -g @useoptic/optic
# Compare the current spec against the one on main
optic diff openapi.yaml --base main --check
En iyisi: çekme istekleri içinde yapılandırılmış değişiklik incelemesi, bozucu veya yasaklı değişiklik olarak neyin sayılacağına dair kurallarla.
Dürüst sınırlama: Node tabanlıdır, bu nedenle tek bir Go ikilisinden daha ağırdır ve ondan en iyi şekilde yararlanmak, yapılandırma ve denetim kurallarını benimsemek anlamına gelir.
Bump.sh CLI
Bump.sh CLI, API belgelerini terminalden yayınlar ve karşılaştırır. Buradaki işbirliği, paylaşılan, her zaman güncel belge ile ilgilidir: spesifikasyon değiştiğinde yeni bir sürüm `deploy` edersiniz ve ekip arkadaşları ile tüketiciler aynı oluşturulmuş referansı okur. `diff` komutu, yayınlanmış sürüm ile yerel dosyanız arasındaki bir değişiklik günlüğünü yayınlar; bu, bir PR yorumuna eklemek için kullanışlıdır. Bir Node paketidir (`bump-cli`), Node 20+ gerektirir ve `preview` ile `diff` bir jeton olmadan çalışır.
# Install
npm install -g bump-cli
# Publish a new version of the shared docs
bump deploy openapi.yaml --doc my-api --token $BUMP_TOKEN
# Or just get the changelog between versions
bump diff openapi.yaml --doc my-api
En iyisi: tek bir paylaşılan, insan tarafından okunabilir belgeyi spesifikasyonla senkronize tutmak, ayrıca inceleme için terminal farkları.
Dürüst sınırlama: barındırılan belgeler ve dağıtım akışı, ücretli bir Bump.sh ürünüdür. CLI istemcidir; paylaşılan yüzey kendi platformlarında yaşar.
Redocly CLI
Redocly CLI, geniş bir OpenAPI araç setidir: spesifikasyonları lintler, paketler ve Redocly kayıt defterine (şimdi Reunite) iter. `push` komutu işbirliği kaldıracıdır; bir spesifikasyon sürümünü paylaşılan bir kayıt defterine yükler, böylece kuruluşun geri kalanı dosyaları dolaştırmak yerine tek bir kanonik kaynaktan çeker. Paketleme de önemlidir, çünkü `$ref` içeren çoklu dosya spesifikasyonu, ekip arkadaşlarınızın kullanabileceği tek bir temiz yapıt haline gelir.
# No install needed; run via npx
npx @redocly/cli lint openapi.yaml
npx @redocly/cli bundle openapi.yaml -o dist/openapi.yaml
# Push a version to the shared registry (needs an API key)
npx @redocly/cli push openapi.yaml --organization "Acme" --project "orders-api"
En iyisi: bir şirket stiline göre lintleme ve tek bir doğruluk kaynağı spesifikasyonunu paylaşılan bir kayıt defterine itme.
Dürüst sınırlama: `lint` ve `bundle` ücretsiz ve yereldir, ancak `push` ve kayıt defteri Redocly'nin barındırılan platformunun bir parçasıdır. Daha derin spesifikasyon düzenleme iş akışları için işbirlikçi API spesifikasyon düzenleme kılavuzumuza bakın.
GitHub CLI (gh)
İncelemeniz çekme isteklerinde gerçekleşiyorsa, GitHub CLI bu akışın tamamını terminale getirir. Tarayıcı açmadan spesifikasyonu değiştiren PR'ı açar, inceleyiciler talep eder ve durumu kontrol edersiniz. Bunu bir Git kancasında oasdiff veya Optic ile eşleştirin, böylece spesifikasyon incelemesi kod incelemesinin normal, betiklenebilir bir parçası haline gelir.
# Open a PR for the spec change and tag reviewers
gh pr create --title "Add /orders pagination" --body "Adds page + limit params"
gh pr review --approve
En iyisi: ekibiniz zaten GitHub'da yaşıyorken, inceleme ve birleştirme konuşmasını kabuktan yürütme.
Dürüst sınırlama: PR'ı yönetir, API semantiğini değil. Bir değişikliğin bozucu olup olmadığını bilmez; oasdiff veya Optic'i bu yüzden bağlarsınız.
Apidog CLI
Apidog CLI buradaki istisnadır. Tek amaçlı bir ikili değildir; Apidog platformuyla aynı tasarım, versiyonlama ve işbirliği verilerine terminalden erişen tam bir proje kaynak CLI'sıdır (`npm install -g apidog-cli`). İşbirliği için üç komut grubu önemlidir: `branch`, `merge-request` ve `git-connection`.
Apidog açık kaynaklı değildir; ücretsiz katmanı olan ticari bir üründür. Ancak bir fark aracını, bir belge yayınlayıcısını ve bir kayıt defterini elle bir araya getirmek istemiyorsanız, ücretsiz katman artı CLI size spesifikasyon dalları, bir inceleme akışı ve Git yedeklemesini tek bir yerde sunar.
İzole bir dalla başlayın. `--type` bayrağı dal modelini seçer: belirli bir özellik veya sürüm için `sprint`, devam eden çalışmalar için `general` veya bir aracının kaynak kodunuza dokunmadan kaynakları düzenlediği izole bir dal için `ai`.
# Install and authenticate
npm install -g apidog-cli
apidog login --with-token $APIDOG_TOKEN
# Start a sprint branch for a shared change
apidog branch create --type sprint --name "orders-pagination"
Dal hazır olduğunda, doğrudan birleştirmek yerine bir birleştirme isteği açın. Bu, inceleme kapısıdır: ana dal korunduğunda, bir düzenleyici isteği oluşturur ve bir yönetici herhangi bir şey birleşmeden önce onaylar. Birleştirmeler yalnızca adlandırdığınız kaynakları seçer, böylece paylaşılan bir değişiklik kapsamlı kalır.
# Propose the change for review (safe against a protected main)
apidog merge-request create --branch "orders-pagination" --endpoint-ids 1,2
Ve `git-connection`, her modülün OpenAPI dosyasını bir Git deposuna yedekler (GitHub, GitLab veya Azure DevOps desteklenir), böylece spesifikasyonunuz kodunuzla birlikte sürüm kontrolünde bir aynaya sahip olur.
# Wire the project's specs to a Git repo for backup + history
apidog git-connection --help
Çıktı, `agentHints.nextSteps` içeren yapılandırılmış JSON'dur, bu da CLI'ı betiklerden veya bir yapay zeka aracısından yönetmeyi kolaylaştırır. Tüm komut referansı için Apidog CLI tam kılavuzuna bakın.
En iyisi: ayrı araçları bir araya getirmeden entegre bir versiyonlama + inceleme + birleştirme akışı, ayrıca ekipler ve aracılar için tasarlanmış dal modelleri.
Dürüst sınırlama: bu bir platform CLI'dır, bu yüzden buradaki en ağır kurulumdur ve çıplak bir yerel dosya yerine Apidog projenizle konuşur. Ayrıca bir OpenAPI linter'ı yoktur; stil kuralları için Redocly veya Spectral kullanın. Ekibinizin dalların yanı sıra rol tabanlı erişime ihtiyacı olduğunda, RBAC ile güvenli API işbirliği hakkında bilgi edinin.
Nasıl seçmeli
Aracı işbirliği görevine uydurun, tersini değil.
| Araç | En İyisi İçin | Kurulum | Açık Kaynak mı? | Notlar |
|---|---|---|---|---|
| Git + spesifikasyon dosyası | Geçmiş ve inceleme, sıfır yeni araç | zaten yüklü | evet (Git) | YAML'de gürültülü; anlamsal bir fark aracıyla eşleştirin |
| oasdiff | Bozucu değişiklik birleştirme kapısı | brew install oasdiff |
evet (Apache 2.0) | Çıkış kodu, CI'da bozulmalarda başarısız olur |
| Optic | PR'larda yapılandırılmış değişiklik incelemesi | npm i -g @useoptic/optic |
evet (MIT) | $ref, oneOf vb. anlar |
| Bump.sh CLI | Paylaşılan belgeleri + farkları yayınlama | npm i -g bump-cli |
CLI açık, barındırma ücretli | Node 20+; diff/preview jeton gerektirmez |
| Redocly CLI | Lintleme, paketleme, kayıt defterine itme | npx @redocly/cli |
CLI açık, kayıt defteri ücretli | push bir API anahtarı gerektirir |
| GitHub CLI | Kabuktan PR incelemesini yönetme | brew install gh |
evet (MIT) | PR'ı yönetir, API semantiğini değil |
| Apidog CLI | Entegre versiyonlama + inceleme + birleştirme | npm i -g apidog-cli |
hayır (ücretsiz katman) | branch / merge-request / git-connection |
Çoğu ekip birkaçını birleştirmeyi tercih eder. Yaygın bir hafif yığın: spesifikasyonu Git'e kaydetmek, birleştirme kapısı olarak oasdiff veya Optic'i çalıştırmak ve Bump.sh veya Redocly ile yayınlamak. Dallanmayı, incelemeyi ve birleştirmeyi tek bir CLI'dan çalıştırmak isterseniz, Apidog üçünü de kapsar. Bir yığın seçimine daha geniş bir bakış için, API işbirliği ekip araçları kılavuzumuz seçenekleri karşılaştırır.
Sonuç
Terminalden işbirliği üç adımdır: spesifikasyonu versiyonlamak, farkı (diff) incelemek, paylaşılan değişikliği birleştirmek. Git birincisini halleder, oasdiff ve Optic ikincisini keskinleştirir, Bump.sh ve Redocly sonucu yayınlar ve gh PR'ı yönlendirir. Apidog CLI, hem ekipler hem de aracılar için oluşturulmuş dal modelleriyle versiyonlama, inceleme ve birleştirmeyi tek bir komut setinde birleştirir.
Araçları bir araya getirmeden entegre bir yol mu istiyorsunuz? Apidog'u indirin, `apidog-cli` kurun ve halihazırda çalıştığınız terminalden ilk `apidog branch create` ve `merge-request` komutlarınızı çalıştırın. CLI'ı CI'a bağlamak oradan kısa bir sonraki adımdır.
