Çoğu API tasarım eğitimi fareyle başlar: görsel düzenleyici açılır, şemalar tuvale sürüklenir ve alanlar diyalog kutularından eklenir. Bu yaklaşım çalışır; ancak API tanımınız Git'te yaşıyor, pull request'lerde inceleniyor ve CI'dan geçiyorsa, tasarımı da dağıtım süreciniz gibi yönetmelisiniz: terminalden, metin tabanlı ve betiklenebilir komutlarla.
Komut satırından API tasarlamak; sözleşmeyi oluşturmak, stil kurallarına göre lint etmek, tek dosyada demetlemek ve sunucu taslakları üretmek demektir. Her adım tekrarlanabilir, CI işlem hattında çalıştırılabilir ve ekip arkadaşları veya yapay zeka ajanları tarafından aynı komutlarla yeniden üretilebilir.
Bu rehber iki yaklaşımı ele alır:
- Açık kaynak araç zinciri: OpenAPI yazma, Spectral ile lint etme, Redocly CLI ile demetleme ve openapi-generator ile kod taslağı oluşturma.
- Apidog CLI yaklaşımı: Şemaları, uç noktaları ve kimlik doğrulamayı terminalden tek bir proje içinde yönetme.
Kavramsal arka plan için API nasıl tasarlanır ve REST API tasarlama rehberlerine bakabilirsiniz.
Apidog ile ilerleyecekseniz önce CLI'ı kurun. Apidog CLI kurulum rehberi, npm install -g apidog-cli ve apidog login --with-token adımlarını kapsar. Komut grupları için tam Apidog CLI rehberini kullanın.
Genel açık kaynak yolu: yaz, lint et, demetle, oluştur
Klasik CLI tabanlı API tasarımı, bağımsız araçları bir işlem hattında birleştirir. OpenAPI tanımını sürüm kontrolünde tutar ve her aracı ayrı bir adım olarak çalıştırırsınız. Bu, Git-tabanlı API tasarım iş akışının temelidir.
Akış şu şekildedir:
openapi.yaml
↓
spectral lint
↓
redocly bundle
↓
openapi-generator
1. OpenAPI belgesini yazın
Bir openapi.yaml dosyasıyla başlayın. Özel bir editör gerekmez; herhangi bir metin editörü yeterlidir.
openapi: 3.0.3
info:
title: Orders API
version: 1.0.0
paths:
/orders/{orderId}:
get:
operationId: getOrder
parameters:
- name: orderId
in: path
required: true
schema:
type: string
responses:
'200':
description: An order
content:
application/json:
schema:
$ref: '#/components/schemas/Order'
components:
schemas:
Order:
type: object
required: [id, status]
properties:
id:
type: string
status:
type: string
enum: [pending, shipped, delivered]
API büyüdükçe şemaları ayrı dosyalara taşıyın ve $ref ile bağlayın. Örneğin:
components:
schemas:
Order:
$ref: ./schemas/order.yaml
Bu yapı, şemaların bağımsız okunmasını ve pull request incelemelerinin daha küçük değişiklikler üzerinden yapılmasını kolaylaştırır.
2. Spectral ile lint edin
Elle yazılan OpenAPI tanımlarında tutarsızlıklar oluşur:
-
operationIdunutulabilir. - Bir response belgesiz kalabilir.
- Alan adları farklı kurallarla yazılabilir.
- Hata yanıtları eksik olabilir.
Spectral bu sorunları CI aşamasından önce yakalamanıza yardımcı olur.
npm install -g @stoplight/spectral-cli
spectral lint openapi.yaml
Çıktıda ihlalin dosyası, satır numarası ve önem seviyesi görünür. CI'da komutun çıkış kodunu kullanarak doğrulama hatalarında build'i durdurabilirsiniz.
Örnek:
spectral lint openapi.yaml || exit 1
Alternatif olarak Redocly CLI veya vacuum kullanabilirsiniz. Önemli olan, lint işlemini ayrı ve zorunlu bir işlem hattı adımı olarak çalıştırmaktır.
3. Redocly CLI ile demetleyin
API tanımı birden fazla dosyaya bölündüyse, kod üreticiler ve dokümantasyon araçları genellikle tek bir dosya bekler. redocly bundle, tüm $ref referanslarını çözer ve tek bir OpenAPI çıktısı üretir.
npm install -g @redocly/cli
mkdir -p dist
redocly bundle openapi.yaml -o dist/openapi.bundled.yaml
Artık dist/openapi.bundled.yaml dosyasını kod üretimi, dokümantasyon veya yayınlama için kullanabilirsiniz.
Redocly CLI lint işlemini de destekler:
redocly lint openapi.yaml
Tüm seçenekler için Redocly CLI resmi belgelerine bakın.
4. openapi-generator ile taslak oluşturun
Lint edilmiş ve demetlenmiş OpenAPI tanımıyla sunucu taslağı veya istemci SDK'sı üretebilirsiniz.
npm install -g @openapitools/openapi-generator-cli
openapi-generator-cli generate \
-i dist/openapi.bundled.yaml \
-g spring \
-o ./server
-g spring yerine hedefinize uygun bir jeneratör kullanın:
# Python Flask sunucusu
openapi-generator-cli generate \
-i dist/openapi.bundled.yaml \
-g python-flask \
-o ./server
# Go sunucusu
openapi-generator-cli generate \
-i dist/openapi.bundled.yaml \
-g go-server \
-o ./server
Bu yaklaşım dört temel adımdan oluşur: yaz, lint et, demetle, oluştur. Maksimum kontrol sağlar; ancak dosya yapısını, linter kurallarını, bundle ayarlarını ve generator yapılandırmasını sizin yönetmeniz gerekir.
Apidog CLI yolu: tek bir projede tasarım
Apidog CLI yaklaşımında şemalar, uç noktalar, sahte veriler ve kimlik doğrulama tek bir proje içinde yönetilir. apidog-cli, yalnızca test çalıştırıcısı değildir; proje kaynaklarını terminalden yönetmek için komut grupları sunar:
-
schema: Veri modelleri -
endpoint: Uç noktalar -
folder: Organizasyon -
security-scheme: Kimlik doğrulama -
import/export: Tanım taşıma -
mock: Sahte veri ve servis işlemleri
Önemli ayrım: Apidog, OpenAPI stil lint'i yapmaz ve stil rehberi uygulamaz. OpenAPI kuralları için Spectral veya vacuum kullanmaya devam etmelisiniz. Apidog ticari bir üründür ve ücretsiz katmanı bulunur. Karşılığında tasarım parçalarını tek tek bağlamak yerine, entegre bir proje modeli sunar.
Bu değiş tokuşla ilgili daha fazla bilgi için API tasarımı ve testi için Swagger alternatifleri yazısına bakın.
1. CLI'ı kurun ve kimlik doğrulayın
npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>
Token kurulumu için Apidog CLI kurulum rehberini kullanın.
Komutların kullanılabilir bayraklarını görmek için --help ekleyin:
apidog --help
apidog schema --help
apidog endpoint --help
Komutlar yapılandırılmış JSON çıktısı döndürür. Çoğu yanıtta sonraki işlemleri belirten agentHints.nextSteps alanı da bulunur.
2. Veri modellerini schema ile tanımlayın
Yeniden kullanılabilir bir Order şeması oluşturmak, uç noktaların aynı sözleşmeye referans vermesini sağlar. Bu, OpenAPI'deki components/schemas yaklaşımına karşılık gelir.
apidog schema --help
apidog schema create --project <PROJECT_ID>
CLI çıktısı JSON olduğu için kimlikleri jq ile alıp sonraki komutlara aktarabilirsiniz:
apidog schema list --project <PROJECT_ID> | jq
Elinizde mevcut bir OpenAPI dosyası varsa, yeniden yazmak yerine içe aktarın:
apidog import --project <PROJECT_ID> --file openapi.yaml
apidog import, OpenAPI 3.x, Swagger 2.0, Postman ve Apidog formatlarını kabul eder. Böylece mevcut tanımınızı doğrudan proje kaynağına dönüştürebilirsiniz.
3. Uç noktaları endpoint ile tanımlayın
Modeller hazır olduğunda işlemleri ekleyin veya güncelleyin.
apidog endpoint --help
apidog endpoint list --project <PROJECT_ID>
apidog endpoint create --project <PROJECT_ID>
Uç nokta listesini JSON olarak almak, otomasyon için kullanışlıdır. Örneğin, beklenen yolların bulunduğunu bir script ile kontrol edebilirsiniz:
apidog endpoint list --project <PROJECT_ID> | jq
İlgili uç noktaları klasörlerle gruplayın:
apidog folder --help
Bu, proje büyüdüğünde kaynakların daha kolay bulunmasını sağlar.
4. Kimlik doğrulamayı security-scheme ile tanımlayın
Kimlik doğrulama sözleşmenin parçasıdır. security-scheme grubu; API anahtarı, bearer token ve OAuth 2.0 gibi kimlik doğrulama mekanizmalarını proje düzeyinde tanımlamanıza yardımcı olur.
apidog security-scheme --help
apidog security-scheme list --project <PROJECT_ID>
Kimlik doğrulamayı proje düzeyinde bir kez tanımlayın ve uç noktaların bu tanıma referans vermesini sağlayın. Her endpoint'te kimlik doğrulamasını tekrar yazmak sözleşme kaymasına yol açabilir.
Bu yapı OpenAPI'deki components/securitySchemes kavramıyla eşleşir; bu nedenle içe ve dışa aktarma akışı korunur.
5. CLI kaynak yazımlarını doğrulayın
Bir kaynak tanımını kaydetmeden veya CI'a göndermeden önce biçiminin geçerli olduğundan emin olun.
apidog cli-schema --help
apidog cli-schema validate --file resource.json
Bu komutu uygulama adımından önce çalıştırın:
apidog cli-schema validate --file resource.json \
&& echo "Kaynak tanımı geçerli"
Sıfır olmayan çıkış kodu, hatalı kaynakların projeye uygulanmasını engeller.
apidog cli-schema validate, OpenAPI stil lint'i değildir. CLI kaynak yapısını doğrular. OpenAPI stil ve kural ihlalleri için Spectral veya vacuum kullanın.
6. OpenAPI'ye geri aktarın
Apidog içinde tasarım yaptıktan sonra taşınabilir bir OpenAPI çıktısı üretebilirsiniz.
mkdir -p dist
apidog export \
--project <PROJECT_ID> \
--format openapi \
-o dist/openapi.yaml
Dışa aktarılan OpenAPI dosyasını diğer araçlara aktarabilirsiniz:
spectral lint dist/openapi.yaml
openapi-generator-cli generate \
-i dist/openapi.yaml \
-g spring \
-o ./server
Apidog projesi ile açık kaynak araç zinciri birbirini dışlamaz. apidog export, iki yaklaşım arasındaki köprüdür.
CI'a entegre etme
Her iki yaklaşım da CI için uygundur çünkü komutlar standart çıktı ve çıkış kodu üretir. Minimal bir kontrol adımı şöyle olabilir:
# OpenAPI stil ihlallerinde başarısız ol
spectral lint openapi.yaml
# Uygulamadan önce CLI kaynak tanımını doğrula
apidog cli-schema validate --file resource.json
# Alt araçlar için tek bir OpenAPI yapıtı üret
mkdir -p dist
redocly bundle openapi.yaml -o dist/openapi.bundled.yaml
Bu akışı bir GitHub Actions, GitLab CI veya başka bir CI ortamına doğrudan ekleyebilirsiniz. Temel sıralama şudur:
- OpenAPI tanımını lint edin.
- Apidog kaynak dosyalarını doğrulayın.
- OpenAPI dosyasını bundle edin.
- İsteğe bağlı olarak kod veya dokümantasyon üretin.
Apidog komutları agentHints.nextSteps içeren JSON döndürdüğü için akış, yapay zeka kodlama ajanları tarafından da yönlendirilebilir. Ajan, çıktıdaki önerilen sonraki adımı okuyup terminal komutunu çalıştırabilir; GUI otomasyonu gerekmez.
Sık karşılaşılan sorunlar
Bölünmüş dosyalar alt araçları bozar
Birçok $ref dosyasına ayrılmış OpenAPI tanımı insanlar için okunabilir olabilir; ancak kod üreticiler ve belge araçları tek dosya bekleyebilir.
Kod üretmeden veya dokümantasyon yayınlamadan önce demetleyin:
redocly bundle openapi.yaml -o dist/openapi.bundled.yaml
Apidog'un lint yapmasını beklemek
Apidog kaynakları yönetir; OpenAPI stil rehberi uygulamaz ve stil ihlallerini işaretlemez.
Bu nedenle işlem hattında Spectral veya vacuum kullanın:
spectral lint openapi.yaml
Ayrıca apidog cli-schema validate komutunu linter olarak değerlendirmeyin. Bu komut CLI kaynak biçimini doğrular; OpenAPI stilini değil.
Düzenlemeden önce içe aktarmayı unutmak
Mevcut bir API'yi Apidog CLI üzerinden düzenlemek istiyorsanız önce tanımı projeye aktarın:
apidog import --project <PROJECT_ID> --file openapi.yaml
Boş bir projede çalışmak, mevcut uç noktaların otomatik olarak görünmesini sağlamaz.
Kimlik doğrulamayı uç nokta başına yeniden tanımlamak
Kimlik doğrulamayı proje düzeyinde security-scheme olarak tanımlayın. Ardından uç noktaların bu tanıma referans vermesini sağlayın. Her işlemde aynı kimlik doğrulama ayrıntılarını tekrar etmek, zamanla tutarsızlık oluşturur.
Özet
CLI tabanlı API tasarımı, GUI tıklamalarını tekrarlanabilir ve otomasyona uygun komutlara dönüştürür.
Açık kaynak yaklaşımı:
OpenAPI yaz
→ Spectral ile lint et
→ Redocly ile bundle et
→ openapi-generator ile üret
Bu yol maksimum kontrol sağlar ve Git tabanlı süreçlere iyi uyar.
Apidog CLI yaklaşımı ise şemaları, uç noktaları ve kimlik doğrulamayı tek bir proje içinde yönetir. Dışa aktarma özelliği sayesinde OpenAPI yapıtını yine Spectral, Redocly veya openapi-generator gibi araçlara aktarabilirsiniz.
Ekibiniz zaten bağımsız CLI araçlarıyla çalışıyorsa bu zinciri koruyun. Tek bir proje içinde yönetilen tasarım kaynakları istiyorsanız, Apidog'u indirin, CLI'ı kurun ve sonraki API'nizi terminalden tasarlayın.
Top comments (0)