REST Spesifikasyonu ile Hiç Yapmadığınız 5 Şey

Çoğu ön uç ve arka uç geliştiricisi, daha önce REST spesifikasyonları ve RESTful API'leri ile ilgilendi. Ancak tüm RESTful API'ler eşit yaratılmamıştır. Aslında, nadiren RESTful olurlar…

RESTful API Nedir ?

Bu bir efsane.

Projenizin bir RESTful API'si olduğunu düşünüyorsanız, büyük olasılıkla yanılıyorsunuz. RESTful API'nin arkasındaki fikir, REST belirtiminde açıklanan tüm mimari kuralları ve sınırlamaları takip edecek şekilde geliştirmektir. Ancak gerçekçi olarak, bu pratikte büyük ölçüde imkansızdır.

Bir yandan, REST çok fazla bulanık ve belirsiz tanım içeriyor. Örneğin uygulamada HTTP yönteminden ve durum kodu sözlüklerinden bazı terimler amaçlarına aykırı olarak kullanılmakta veya hiç kullanılmamaktadır.

Öte yandan, REST geliştirme çok fazla sınırlama yaratır. Örneğin, atomik kaynak kullanımı, mobil uygulamalarda kullanılan gerçek dünya API'leri için yetersizdir. İstekler arasında veri depolamanın tamamen reddedilmesi, hemen hemen her yerde görülen “kullanıcı oturumu” mekanizmasını esasen yasaklar.

Ama bekleyin, o kadar da kötü değil!

REST API Spesifikasyonuna Ne İçin İhtiyacınız Var?

Bu dezavantajlara rağmen, mantıklı bir yaklaşımla REST, gerçekten harika API'ler oluşturmak için hala harika bir konsepttir. Bu API'ler tutarlı olabilir ve net bir yapıya, iyi belgelere ve yüksek birim test kapsamına sahip olabilir. Tüm bunları yüksek kaliteli bir API spesifikasyonu ile elde edebilirsiniz.

Genellikle bir REST API belirtimi, belgeleriyle ilişkilendirilir. Bir spesifikasyonun (API'nizin resmi açıklaması) aksine, dokümantasyonun insan tarafından okunabilir olması amaçlanmıştır: örneğin, API'nizi kullanan mobil veya web uygulamasının geliştiricileri tarafından okunabilir.

Doğru bir API açıklaması, yalnızca API belgelerini iyi yazmakla ilgili değildir. Bu yazıda nasıl yapabileceğinize dair örnekler paylaşmak istiyorum:

• Birim testlerinizi daha basit ve daha güvenilir hale getirin;
• Kullanıcı girişi ön işlemesini ve doğrulamasını ayarlayın;
• Serileştirmeyi otomatikleştirin ve yanıt tutarlılığını sağlayın; ve hatta
• Statik yazmanın avantajlarından yararlanın.

Ama önce, API spesifikasyon dünyasına bir girişle başlayalım.

OpenAPI

OpenAPI, şu anda REST API spesifikasyonları için en yaygın olarak kabul edilen formattır. Spesifikasyon, üç bölümden oluşan JSON veya YAML formatında tek bir dosyada yazılır:

1. API adı, açıklaması ve sürümünün yanı sıra ek bilgileri içeren bir başlık.
2. Tanımlayıcılar, HTTP yöntemleri, tüm giriş parametreleri, yanıt kodları ve gövde veri türleri dahil olmak üzere tüm kaynakların tanımlarına bağlantılar içeren açıklamaları.
3. Giriş veya çıkış için kullanılabilecek tüm tanımlar, JSON Şema biçiminde (bu, evet, YAML'de de gösterilebilir.)

OpenAPI'nin yapısının iki önemli dezavantajı vardır: Çok karmaşık ve bazen gereksizdir. Küçük bir proje, binlerce satırlık bir JSON spesifikasyonuna sahip olabilir. Bu dosyanın bakımını manuel olarak yapmak imkansız hale gelir. Bu, API geliştirilirken spesifikasyonun güncel tutulması fikrine yönelik önemli bir tehdittir.

Bir API tanımlamanıza ve OpenAPI çıktısı üretmenize izin veren birden çok düzenleyici vardır. Bunlara dayalı ek hizmetler ve bulut çözümleri arasında Swagger, Apiary, Stoplight, Restlet ve diğerleri bulunur.

Ancak, hızlı spesifikasyon düzenlemenin karmaşıklığı ve kod değişiklikleriyle uyumlu hale getirilmesi nedeniyle bu hizmetler benim için elverişsizdi. Ek olarak, özelliklerin listesi belirli bir hizmete bağlıydı. Örneğin, bir bulut hizmetinin araçlarına dayalı tam teşekküllü birim testleri oluşturmak neredeyse imkansızdır. Kod oluşturma ve alaycı uç noktalar, pratik gibi görünse de, pratikte çoğunlukla işe yaramaz hale geliyor. Bunun nedeni çoğunlukla, uç nokta davranışının genellikle kullanıcı izinleri ve giriş parametreleri gibi çeşitli şeylere bağlı olmasıdır; bunlar bir API mimarı için aşikar olabilir, ancak bir OpenAPI spesifikasyonundan otomatik olarak oluşturulması kolay değildir.

Tinyspec

Bu yazıda, kendi REST API tanım formatım olan tinyspec'e dayalı örnekler kullanacağım. Tanımlar, sezgisel bir söz dizimine sahip küçük dosyalardan oluşur. Bir projede kullanılan uç noktaları ve veri modellerini tanımlarlar. Dosyalar, kodun yanında depolanarak hızlı bir başvuru ve kod yazma sırasında düzenlenebilirlik sağlar. Tinyspec, projenizde hemen kullanılabilecek tam teşekküllü bir OpenAPI biçiminde otomatik olarak derlenir.

Node.js (Koa, Express) ve Ruby on Rails örneklerini de kullanacağım, ancak göstereceğim uygulamalar Python, PHP ve Java dahil çoğu teknolojiye uygulanabilir.

API Spesifikasyonunun Etkilendiği Yer

Artık biraz geçmişe sahip olduğumuza göre, uygun şekilde belirlenmiş bir API'den en iyi şekilde nasıl yararlanabileceğimizi keşfedebiliriz.

1. Uç Nokta Birim Testleri

Davranışa dayalı geliştirme (BDD), REST API'leri geliştirmek için idealdir. Ayrı sınıflar, modeller veya denetleyiciler için değil, belirli uç noktalar için birim testleri yazmak en iyisidir. Her testte gerçek bir HTTP isteğine öykünür ve sunucunun yanıtını doğrularsınız. Node.js için istekleri taklit etmek için en süper ve chai-http paketleri vardır ve Ruby on Rails için havadan paketler vardır.

Diyelim ki bir User şemamız ve tüm kullanıcıları döndüren bir GET /users uç noktamız var. İşte bunu açıklayan bazı tinyspec sözdizimi:

 # user.models.tinyspec User {name, isAdmin: b, age?: i} # users.endpoints.tinyspec GET /users => {users: User[]}

Ve ilgili testi şu şekilde yazacağız:

Node.js

 describe('/users', () => { it('List all users', async () => { const { status, body: { users } } = request.get('/users'); expect(status).to.equal(200); expect(users[0].name).to.be('string'); expect(users[0].isAdmin).to.be('boolean'); expect(users[0].age).to.be.oneOf(['boolean', null]); }); });

raylar üzerinde yakut

 describe 'GET /users' do it 'List all users' do get '/users' expect_status(200) expect_json_types('users.*', { name: :string, isAdmin: :boolean, age: :integer_or_null, }) end end

Sunucu yanıtlarını açıklayan belirtime zaten sahip olduğumuzda, testi basitleştirebilir ve yanıtın belirtime uyup uymadığını kontrol edebiliriz. Her biri JSON Şema biçimini izleyen bir OpenAPI belirtimine dönüştürülebilen tinyspec modelleri kullanabiliriz.

JS'deki herhangi bir değişmez nesne (veya Ruby'de Hash , Python'da dict , PHP'de ilişkisel dizi ve hatta Java'da Map ) JSON Schema uyumluluğu için doğrulanabilir. Çerçeveleri test etmek için uygun eklentiler bile vardır, örneğin jest-ajv (npm), chai-ajv-json-schema (npm) ve RSpec (rubygem) için json_matchers.

Şemaları kullanmadan önce onları projeye aktaralım. İlk olarak, Tinyspec belirtimine dayalı olarak openapi.json dosyasını oluşturun (bunu her test çalıştırmasından önce otomatik olarak yapabilirsiniz):

 tinyspec -j -o openapi.json

Node.js

Artık oluşturulan JSON'u projede kullanabilir ve ondan definitions anahtarını alabilirsiniz. Bu anahtar, tüm JSON şemalarını içerir. Şemalar çapraz referanslar ( $ref ) içerebilir, bu nedenle herhangi bir gömülü şemanız varsa (örneğin, Blog {posts: Post[]} ), doğrulamada kullanmak için bunları açmanız gerekir. Bunun için json-schema-deref-sync (npm) kullanacağız.

 import deref from 'json-schema-deref-sync'; const spec = require('./openapi.json'); const schemas = deref(spec).definitions; describe('/users', () => { it('List all users', async () => { const { status, body: { users } } = request.get('/users'); expect(status).to.equal(200); // Chai expect(users[0]).to.be.validWithSchema(schemas.User); // Jest expect(users[0]).toMatchSchema(schemas.User); }); });

raylar üzerinde yakut

json_matchers modülü $ref referanslarını nasıl işleyeceğini bilir, ancak belirtilen konumda ayrı şema dosyaları gerektirir, bu nedenle önce swagger.json dosyasını birden çok küçük dosyaya bölmeniz gerekir:

 # ./spec/support/json_schemas.rb require 'json' require 'json_matchers/rspec' JsonMatchers.schema_root = 'spec/schemas' # Fix for json_matchers single-file restriction file = File.read 'spec/schemas/openapi.json' swagger = JSON.parse(file, symbolize_names: true) swagger[:definitions].keys.each do |key| File.open("spec/schemas/#{key}.json", 'w') do |f| f.write(JSON.pretty_generate({ '$ref': "swagger.json#/definitions/#{key}" })) end end

Testin nasıl görüneceği aşağıda açıklanmıştır:

 describe 'GET /users' do it 'List all users' do get '/users' expect_status(200) expect(result[:users][0]).to match_json_schema('User') end end

Testleri bu şekilde yazmak inanılmaz derecede uygundur. Özellikle IDE'niz testlerin çalıştırılmasını ve hata ayıklamayı destekliyorsa (örneğin, WebStorm, RubyMine ve Visual Studio). Bu şekilde diğer yazılımları kullanmaktan kaçınabilirsiniz ve tüm API geliştirme döngüsü üç adımla sınırlıdır:

1. Tinyspec dosyalarında belirtimi tasarlama.
2. Eklenen/düzenlenen uç noktalar için tam bir test seti yazma.
3. Testleri karşılayan kodu uygulamak.

2. Girdi Verilerini Doğrulama

OpenAPI, yalnızca yanıt biçimini değil, aynı zamanda giriş verilerini de tanımlar. Bu, kullanıcı tarafından gönderilen verileri çalışma zamanında doğrulamanıza ve tutarlı ve güvenli veritabanı güncellemeleri sağlamanıza olanak tanır.

Bir kullanıcı kaydının yamalanmasını ve güncellenmesine izin verilen tüm kullanılabilir alanları açıklayan aşağıdaki belirtime sahip olduğumuzu varsayalım:

 # user.models.tinyspec UserUpdate !{name?, age?: i} # users.endpoints.tinyspec PATCH /users/:id {user: UserUpdate} => {success: b}

Önceden, test içi doğrulama için eklentileri araştırdık, ancak daha genel durumlar için ajv (npm) ve json-schema (rubygem) doğrulama modülleri var. Bunları doğrulamalı bir denetleyici yazmak için kullanalım:

Node.js (Koa)

Bu, Express'in halefi olan Koa için bir örnektir - ancak eşdeğer Express kodu benzer görünecektir.

 import Router from 'koa-router'; import Ajv from 'ajv'; import { schemas } from './schemas'; const router = new Router(); // Standard resource update action in Koa. router.patch('/:id', async (ctx) => { const updateData = ctx.body.user; // Validation using JSON schema from API specification. await validate(schemas.UserUpdate, updateData); const user = await User.findById(ctx.params.id); await user.update(updateData); ctx.body = { success: true }; }); async function validate(schema, data) { const ajv = new Ajv(); if (!ajv.validate(schema, data)) { const err = new Error(); err.errors = ajv.errors; throw err; } }

Bu örnekte, giriş belirtimle eşleşmezse sunucu bir 500 Internal Server Error yanıtı verir. Bunu önlemek için, doğrulayıcı hatasını yakalayabilir ve doğrulamada başarısız olan belirli alanlar hakkında daha ayrıntılı bilgiler içeren kendi yanıtımızı oluşturabilir ve belirtimi takip edebiliriz.

FieldsValidationError için tanım ekleyelim:

 # error.models.tinyspec Error {error: b, message} InvalidField {name, message} FieldsValidationError < Error {fields: InvalidField[]}

Şimdi bunu olası uç nokta yanıtlarından biri olarak sıralayalım:

 # users.endpoints.tinyspec PATCH /users/:id {user: UserUpdate} => 200 {success: b} => 422 FieldsValidationError

Bu yaklaşım, istemciden geçersiz veriler geldiğinde hata senaryolarının doğruluğunu test eden birim testleri yazmanıza olanak tanır.

3. Model Serileştirme

Hemen hemen tüm modern sunucu çerçeveleri, bir şekilde nesne ilişkisel eşlemeyi (ORM) kullanır. Bu, bir API'nin kullandığı kaynakların çoğunun modeller, bunların örnekleri ve koleksiyonları tarafından temsil edildiği anlamına gelir.

Yanıtta gönderilecek bu varlıklar için JSON temsillerini oluşturma işlemine serileştirme denir.

Serileştirme yapmak için bir dizi eklenti vardır: Örneğin, sekelize-json (npm), act_as_api (rubygem) ve jsonapi-rails (rubygem). Temel olarak, bu eklentiler, JSON nesnesine dahil edilmesi gereken belirli bir model için alanların listesini ve ek kuralları sağlamanıza izin verir. Örneğin, alanları yeniden adlandırabilir ve değerlerini dinamik olarak hesaplayabilirsiniz.

Bir model için birkaç farklı JSON temsiline ihtiyacınız olduğunda veya nesne, iç içe geçmiş varlıklar (ilişkiler) içerdiğinde zorlaşır. Ardından kalıtım, yeniden kullanım ve serileştirici bağlama gibi özelliklere ihtiyaç duymaya başlarsınız.

Farklı modüller farklı çözümler sunar, ancak şunu düşünelim: Spesifikasyon tekrar yardımcı olabilir mi? Temel olarak JSON temsillerine ilişkin tüm bilgiler, gömülü varlıklar dahil olmak üzere tüm olası alan kombinasyonları zaten içindedir. Bu da tek bir otomatik serileştirici yazabileceğimiz anlamına gelir.

Sequelize modelleri için bunu yapmayı destekleyen küçük sequelize-serialize (npm) modülünü sunayım. Bir model örneğini veya bir diziyi ve gerekli şemayı kabul eder ve ardından serileştirilmiş nesneyi oluşturmak için bunun üzerinden yinelenir. Ayrıca tüm gerekli alanları hesaba katar ve ilişkili varlıkları için iç içe şemaları kullanır.

Diyelim ki blogdaki gönderileri olan tüm kullanıcıları, bu gönderilere yapılan yorumlar da dahil olmak üzere API'den döndürmemiz gerekiyor. Bunu aşağıdaki özelliklerle tanımlayalım:

 # models.tinyspec Comment {authorId: i, message} Post {topic, message, comments?: Comment[]} User {name, isAdmin: b, age?: i} UserWithPosts < User {posts: Post[]} # blogUsers.endpoints.tinyspec GET /blog/users => {users: UserWithPosts[]}

Şimdi isteği Sequelize ile oluşturabilir ve yukarıda açıklanan spesifikasyona tam olarak karşılık gelen serileştirilmiş nesneyi döndürebiliriz:

 import Router from 'koa-router'; import serialize from 'sequelize-serialize'; import { schemas } from './schemas'; const router = new Router(); router.get('/blog/users', async (ctx) => { const users = await User.findAll({ include: [{ association: User.posts, required: true, include: [Post.comments] }] }); ctx.body = serialize(users, schemas.UserWithPosts); });

Bu neredeyse büyülü, değil mi?

4. Statik Yazma

TypeScript veya Flow kullanmak için yeterince iyiyseniz, "Değerli statik türlerimden ne haber?" diye sormuş olabilirsiniz. sw2dts veya swagger-to-flowtype modülleriyle, JSON şemalarına dayalı olarak gerekli tüm statik türleri oluşturabilir ve bunları testlerde, denetleyicilerde ve serileştiricilerde kullanabilirsiniz.

 tinyspec -j sw2dts ./swagger.json -o Api.d.ts --namespace Api

Artık türleri denetleyicilerde kullanabiliriz:

 router.patch('/users/:id', async (ctx) => { // Specify type for request data object const userData: Api.UserUpdate = ctx.request.body.user; // Run spec validation await validate(schemas.UserUpdate, userData); // Query the database const user = await User.findById(ctx.params.id); await user.update(userData); // Return serialized result const serialized: Api.User = serialize(user, schemas.User); ctx.body = { user: serialized }; });

Ve testler:

 it('Update user', async () => { // Static check for test input data. const updateData: Api.UserUpdate = { name: MODIFIED }; const res = await request.patch('/users/1', { user: updateData }); // Type helper for request response: const user: Api.User = res.body.user; expect(user).to.be.validWithSchema(schemas.User); expect(user).to.containSubset(updateData); });

Oluşturulan tür tanımlarının yalnızca API projesinde değil, aynı zamanda API ile çalışan işlevlerdeki türleri tanımlamak için istemci uygulama projelerinde de kullanılabileceğini unutmayın. (Açısal geliştiriciler bundan özellikle mutlu olacaklardır.)

5. Sorgu Dize Türlerini Döküm

API'niz herhangi bir nedenle application/x-www-form-urlencoded MIME türünde application/json yerine istekleri tüketiyorsa, istek gövdesi şöyle görünür:

 param1=value&param2=777&param3=false

Aynısı sorgu parametreleri için de geçerlidir (örneğin, GET isteklerinde). Bu durumda, web sunucusu türleri otomatik olarak tanıyamaz: Tüm veriler dize biçiminde olacaktır, bu nedenle ayrıştırmadan sonra şu nesneyi alırsınız:

 { param1: 'value', param2: '777', param3: 'false' }

Bu durumda, istek şema doğrulamasında başarısız olur, bu nedenle doğru parametre biçimlerini manuel olarak doğrulamanız ve bunları doğru türlere aktarmanız gerekir.

Tahmin edebileceğiniz gibi, şartnamedeki eski güzel şemalarımızla yapabilirsiniz. Diyelim ki bu uç noktaya ve aşağıdaki şemaya sahibiz:

 # posts.endpoints.tinyspec GET /posts?PostsQuery # post.models.tinyspec PostsQuery { search, limit: i, offset: i, filter: { isRead: b } }

Bu uç noktaya yönelik istek şu şekilde görünür:

 GET /posts?search=needle&offset=10&limit=1&filter[isRead]=true

Tüm parametreleri gerekli türlere dönüştürmek için castQuery işlevini yazalım:

 function castQuery(query, schema) { _.mapValues(query, (value, key) => { const { type } = schema.properties[key] || {}; if (!value || !type) { return value; } switch (type) { case 'integer': return parseInt(value, 10); case 'number': return parseFloat(value); case 'boolean': return value !== 'false'; default: return value; } }); }

Şema ile yayınlama (npm) modülünde iç içe şemalar, diziler ve null türleri destekleyen daha eksiksiz bir uygulama mevcuttur. Şimdi kodumuzda kullanalım:

 router.get('/posts', async (ctx) => { // Cast parameters to expected types const query = castQuery(ctx.query, schemas.PostsQuery); // Run spec validation await validate(schemas.PostsQuery, query); // Query the database const posts = await Post.search(query); // Return serialized result ctx.body = { posts: serialize(posts, schemas.Post) }; });

Dört kod satırından üçünün belirtim şemalarını kullandığını unutmayın.

En İyi Uygulamalar

Burada izleyebileceğimiz birkaç en iyi uygulama var.

Ayrı Oluşturma ve Düzenleme Şemaları Kullanın

Genellikle sunucu yanıtlarını tanımlayan şemalar, girdileri tanımlayanlardan farklıdır ve modeller oluşturmak ve düzenlemek için kullanılır. Örneğin, POST ve PATCH isteklerinde bulunan alanların listesi kesinlikle sınırlandırılmalıdır ve PATCH genellikle tüm alanlar isteğe bağlı olarak işaretlenir. Yanıtı açıklayan şemalar daha serbest biçimli olabilir.

CRUDL uç noktalarını otomatik olarak oluşturduğunuzda, tinyspec New ve Update son eklerini kullanır. User* şemaları şu şekilde tanımlanabilir:

 User {id, email, name, isAdmin: b} UserNew !{email, name} UserUpdate !{email?, name?}

Eski şemaların yeniden kullanılması veya devralınması nedeniyle kazara oluşan güvenlik sorunlarından kaçınmak için farklı eylem türleri için aynı şemaları kullanmamaya çalışın.

Şema Adlandırma Kurallarını Takip Edin

Aynı modellerin içeriği farklı uç noktalar için farklılık gösterebilir. Farkı ve amacı göstermek için şema adlarında With* ve For* son eklerini kullanın. Tinyspec'te modeller birbirlerinden de miras alabilir. Örneğin:

 User {name, surname} UserWithPhotos < User {photos: Photo[]} UserForAdmin < User {id, email, lastLoginAt: d}

Postfixler değiştirilebilir ve birleştirilebilir. Adları yine de özü yansıtmalı ve belgelerin okunmasını kolaylaştırmalıdır.

İstemci Türüne Göre Uç Noktaları Ayırma

Genellikle aynı uç nokta, istemci türüne veya isteği gönderen kullanıcının rolüne göre farklı veriler döndürür. Örneğin, GET /users ve GET /messages uç noktaları, mobil uygulama kullanıcıları ve arka ofis yöneticileri için önemli ölçüde farklı olabilir. Uç nokta adının değiştirilmesi ek yük olabilir.

Aynı uç noktayı birden çok kez tanımlamak için, onun türünü yoldan sonra parantez içinde ekleyebilirsiniz. Bu aynı zamanda etiket kullanımını da kolaylaştırır: Uç nokta belgelerini, her biri belirli bir API istemci grubuna yönelik gruplara ayırırsınız. Örneğin:

 Mobile app: GET /users (mobile) => UserForMobile[] CRM admin panel: GET /users (admin) => UserForAdmin[]

REST API Dokümantasyon Araçları

Tinyspec veya OpenAPI formatında spesifikasyonu aldıktan sonra, HTML formatında güzel görünümlü belgeler oluşturabilir ve yayınlayabilirsiniz. Bu, API'nizi kullanan geliştiricileri mutlu edecektir ve bir REST API dokümantasyon şablonunu elle doldurmaktan kesinlikle daha iyidir.

Daha önce bahsedilen bulut hizmetlerinden ayrı olarak, OpenAPI 2.0'ı HTML ve PDF'ye dönüştüren ve herhangi bir statik barındırmaya dağıtılabilen CLI araçları vardır. İşte bazı örnekler:

• bootprint-openapi (npm, Tinyspec'te varsayılan olarak kullanılır)
• swagger2markup-cli (kavanoz, bir kullanım örneği var, tinyspec Cloud'da kullanılacak)
• redoc-cli (npm)
• widdershins (npm)

Daha fazla örneğiniz var mı? Onları yorumlarda paylaşın.

Ne yazık ki, bir yıl önce piyasaya sürülmesine rağmen, OpenAPI 3.0 hala yeterince desteklenmiyor ve hem bulut çözümlerinde hem de CLI araçlarında buna dayalı uygun belge örnekleri bulamadım. Aynı nedenle, tinyspec henüz OpenAPI 3.0'ı desteklemiyor.

GitHub'da Yayınlama

Belgeleri yayınlamanın en basit yollarından biri GitHub Pages'dir. Depo ayarlarında /docs klasörünüz için statik sayfalar için desteği etkinleştirin ve HTML belgelerini bu klasörde saklayın.

Her bir işlemden sonra belgeleri otomatik olarak güncellemek için scripts/package.json dosyanıza tinyspec veya farklı bir CLI aracı aracılığıyla belge oluşturma komutunu ekleyebilirsiniz:

 "scripts": { "docs": "tinyspec -h -o docs/", "precommit": "npm run docs" }

Sürekli Entegrasyon

CI döngünüze belge oluşturma ekleyebilir ve bunu örneğin, ortama veya API sürümüne bağlı olarak farklı adresler altında Amazon S3'te yayınlayabilirsiniz ( /docs/2.0 , /docs/stable ve /docs/staging gibi).

Tinyspec Bulut

Tinyspec söz dizimini beğendiyseniz, tinyspec.cloud'u erken benimseyen biri olabilirsiniz. Çok çeşitli şablonlar ve kişiselleştirilmiş şablonlar geliştirme yeteneği ile belgelerin otomatik olarak dağıtılması için buna dayalı bir bulut hizmeti ve bir CLI oluşturmayı planlıyoruz.

REST Spesifikasyonu: Muhteşem Bir Efsane

REST API geliştirme, muhtemelen modern web ve mobil servis geliştirmedeki en keyifli süreçlerden biridir. Tarayıcı, işletim sistemi ve ekran boyutunda hayvanat bahçeleri yok ve her şey tamamen kontrolünüz altında, parmaklarınızın ucunda.

Bu süreç, otomasyon desteği ve güncel özellikler sayesinde daha da kolaylaşıyor. Tanımladığım yaklaşımları kullanan bir API, iyi yapılandırılmış, şeffaf ve güvenilir hale gelir.

Sonuç olarak, eğer bir efsane yapıyorsak, neden onu harika bir efsane yapmıyoruz?