- Konu sahibi
- #1
İlk JSON API’nizi oluşturmak için Rails’i API-only modunda başlatın, bir kaynak üretin, rotayı tanımlayın ve istemci isteğini
API-only uygulama, HTML görünümü ve tarayıcıya yönelik gereksiz katmanlar yerine JSON yanıtları üretmeye odaklanır. Ruby ve Rails kurulu bir terminalde uygulamayı şu komutla oluşturun:
Ardından
Scaffold komutu
Bu tek tanım, gönderileri listeleme, tek gönderiyi görüntüleme, yeni gönderi oluşturma, güncelleme ve silme için REST rotaları oluşturur. İlgili HTTP istekleri şöyledir:
Scaffold tarafından oluşturulan denetleyici, modelleri JSON biçiminde döndürür. Bunun nedeni API-only Rails uygulamalarında isteklerin genellikle
İşleyişi açıkça görmek için
Geçersiz verilerin kaydedilmesini önlemek için
Sunucuyu başlatın:
Varsayılan yerel adres üzerinden yeni kayıt oluşturmak için başka bir terminalde şu isteği gönderin:
İstek başarılıysa yanıt gövdesinde
Kayıtları görmek için:
Sonuç bir JSON dizisiyse listeleme rotası çalışıyor demektir. Kayıt yoksa genellikle API bozuk değildir; veritabanında henüz kayıt bulunmadığını gösterir.
Başlığı boş gönderirseniz doğrulama başarısız olur:
Bu durumda beklenen sonuç
Geliştirme aşamasında doğrudan
curl veya benzeri bir araçla test edin. Aşağıdaki örnekte Post kaynağı üzerinden çalışan temel bir CRUD API hazırlanır; başarılı isteklerde JSON, hatalı isteklerde ise HTTP durum koduyla birlikte hata bilgisi döner.API-only Rails uygulaması oluşturma
API-only uygulama, HTML görünümü ve tarayıcıya yönelik gereksiz katmanlar yerine JSON yanıtları üretmeye odaklanır. Ruby ve Rails kurulu bir terminalde uygulamayı şu komutla oluşturun:
Bash:
rails new blog_api --api
cd blog_api
Ardından
Post modeli, veritabanı tablosu, denetleyici ve temel rotaları birlikte üretin:
Bash:
bin/rails generate scaffold Post title:string body:text
bin/rails db:migrate
db:migrate komutu, posts tablosunu veritabanında oluşturur. Bu adım çalıştırılmadığında uygulama kaynak kodunu tanıyabilir ancak tablo bulunmadığı için istekler veritabanı hatasıyla sonuçlanır.Scaffold komutu
app/models/post.rb, app/controllers/posts_controller.rb, migration dosyası, rota tanımı ve test dosyaları gibi temel parçaları oluşturur. Küçük bir örnek için bu üretim yeterlidir; gerçek projede oluşturulan denetleyiciyi uygulamanın yetkilendirme, doğrulama ve iş kurallarına göre düzenlemeniz gerekir.Rotayı ve JSON yanıtlarını düzenleme
config/routes.rb dosyasında resources :posts satırının bulunduğunu kontrol edin:
Ruby:
Rails.application.routes.draw do
resources :posts
end
Bu tek tanım, gönderileri listeleme, tek gönderiyi görüntüleme, yeni gönderi oluşturma, güncelleme ve silme için REST rotaları oluşturur. İlgili HTTP istekleri şöyledir:
| İşlem | HTTP isteği | Beklenen durum |
|---|---|---|
| Listeleme | GET /posts | 200 OK |
| Tek kayıt | GET /posts/:id | 200 OK |
| Oluşturma | POST /posts | 201 Created |
| Güncelleme | PATCH /posts/:id | 200 OK |
| Silme | DELETE /posts/:id | 204 No Content |
Accept: application/json başlığıyla karşılanması ve denetleyicinin HTML şablonu yerine serileştirilebilir nesne döndürmesidir.Örnek denetleyici
İşleyişi açıkça görmek için
app/controllers/posts_controller.rb dosyasını şu yapıya yaklaştırabilirsiniz:
Ruby:
class PostsController < ApplicationController
before_action :set_post, only: %i[show update destroy]
def index
render json: Post.all
end
def show
render json: @post
end
def create
post = Post.new(post_params)
if post.save
render json: post, status: :created
else
render json: { errors: post.errors.full_messages }, status: :unprocessable_entity
end
end
def update
if @post.update(post_params)
render json: @post
else
render json: { errors: @post.errors.full_messages }, status: :unprocessable_entity
end
end
def destroy
@post.destroy
head :no_content
end
private
def set_post
@post = Post.find(params[:id])
end
def post_params
params.require(:post).permit(:title, :body)
end
end
post_params içindeki permit çağrısı, istemcinin yalnızca izin verilen alanları değiştirmesini sağlar. Yeni bir alan eklediğinizde hem migration ile veritabanını hem de bu izin listesini güncellemeniz gerekir.Doğrulama ekleyip API’yi çalıştırma
Geçersiz verilerin kaydedilmesini önlemek için
app/models/post.rb dosyasına bir doğrulama ekleyin:
Ruby:
class Post < ApplicationRecord
validates :title, presence: true
end
Sunucuyu başlatın:
Bash:
bin/rails server
Varsayılan yerel adres üzerinden yeni kayıt oluşturmak için başka bir terminalde şu isteği gönderin:
Bash:
curl -X POST http://localhost:3000/posts \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-d '{"post":{"title":"İlk yazı","body":"Rails JSON API örneği"}}'
İstek başarılıysa yanıt gövdesinde
id, title, body, created_at ve updated_at gibi alanları içeren JSON görürsünüz. HTTP durumunun 201 Created olması, kaydın veritabanına yazıldığı anlamına gelir; yalnızca JSON gövdesinin dönmesi, tek başına kalıcı kayıt yapıldığını kanıtlamaz.Kayıtları görmek için:
Bash:
curl -H "Accept: application/json" http://localhost:3000/posts
Sonuç bir JSON dizisiyse listeleme rotası çalışıyor demektir. Kayıt yoksa genellikle API bozuk değildir; veritabanında henüz kayıt bulunmadığını gösterir.
Başlığı boş gönderirseniz doğrulama başarısız olur:
Bash:
curl -X POST http://localhost:3000/posts \
-H "Content-Type: application/json" \
-d '{"post":{"body":"Başlıksız kayıt"}}'
Bu durumda beklenen sonuç
422 Unprocessable Entity ve errors alanı içeren JSON’dur. Bu yanıt, istemci verisinin kurallara uymadığını gösterir; isteği aynı biçimde tekrar göndermek yerine eksik title değerini ekleyerek yeniden göndermelisiniz.Bulunamayan kayıt ve üretim güvenliği
GET /posts/999999 gibi veritabanında olmayan bir kimlik istenirse Post.find kaydı bulamayarak hata üretir. API’nin istemciye düzenli JSON hata yanıtı vermesini istiyorsanız uygulama düzeyinde ActiveRecord::RecordNotFound için hata işleyicisi tanımlayın ve uygun olarak 404 Not Found döndürün. 404, sunucunun çalışmadığını değil, istenen kaydın bulunamadığını belirtir.Geliştirme aşamasında doğrudan
Post.all kullanmak yeterli olabilir; üretimde kimlik doğrulama, yetkilendirme, sayfalama, sıralama, hassas alanların JSON’dan çıkarılması ve ortak hata biçimi ayrıca ele alınmalıdır. API’ye herkese açık erişim vermeden önce özellikle create, update ve destroy işlemlerinin hangi kullanıcılar tarafından yapılabileceğini sınırlandırın.