Əsas məzmuna keçin

API Design

API Design tətbiqlərin fərqli komponentləri arasında kommunikasiya protokollarının yaradılması prosesidir. Yaxşı API dizaynı sistemin genişləndirilə bilməsini, saxlanmasını və istifadəsini asanlaşdırır.

Nə üçün lazımdır?​

  • Aydın kommunikasiya: Sistemlər arasında standartlaşdırılmış əlaqə
  • Təkrar istifadə: Kodun müxtəlif yerlərində istifadəsi
  • Scalability: Sistemin böyüməsinə uyğunlaşma
  • Maintainability: Sadə saxlama və yeniləmə
  • Interoperability: Fərqli sistemlərin birlikdə işləməsi

API Növləri​

  • REST: HTTP metodları ilə resurs əsaslı dizayn
  • GraphQL: Məlumatların dəqiq sorğulanması
  • gRPC: Yüksək performanslı RPC protokolu
  • WebSocket: Real-time əlaqə üçün
  • SOAP: XML əsaslı protokol

Performance Optimallaşdırması​

  • Pagination: Böyük nəticələrin hissə-hissə göndərilməsi. Yaddaş istifadəsini azaldır. Cavab vaxtını qısaldır
  • Async Logging: Girişlərin asinxron yazılması performansı artırır. Bloklanmanı minimuma endirir
  • Caching: Tez-tez soruşulan məlumatların saxlanması, sürətləndirmə. Server yükünü azaldır
  • Payload Compression: Məlumatın ötürülmə ölçüsünü kiçiltmək üçün sıxılma. Şəbəkə trafikini azaldır
  • Connection Pool: Mövcud əlaqələrin təkrar istifadəsi, gecikməni azaldır. Resurs istehlakını optimallaşdırır

Dizayn Yanaşmaları​

  • Code First: API əvvəlcə kod kimi hazırlanır, sonra sənədləşdirilir. Tez başlamaq üçün yaxşı. Sənədləşdirmə problemi
  • API First: API dizaynı əvvəlcə hazırlanır, sonra kod yazılır. Daha planlı və standartlıdır. Komandalar arası koordinasiya yaxşı

REST API Prinsipi​

  • Plural Resource Names: Resurs adları çoxluq şəklində istifadə edilir (məsələn, /users, /orders). Daha aydın və REST prinsiplərinə uyğundur
  • HTTP Methods: GET (oxumaq), POST (yaratmaq), PUT (yeniləmək), DELETE (silmək)
  • Status Codes: 2xx (müvəffəq), 4xx (client səhvi), 5xx (server səhvi)
  • Stateless: Hər sorğu müstəqildir

Etibarlılıq və Təhlükəsizlik​

  • Idempotency: Eyni əməliyyatın təkrar icrası nəticəni dəyişdirməməlidir. PUT və DELETE idempotentdir, POST olmaya bilər
  • Rate Limiting: İstifadəçi sorğularının sayı müəyyən limitlə məhdudlaşdırılır. Server yüklənməsinin qarşısını alır
  • Authentication: JWT, OAuth, API keys ilə kimlik doğrulama
  • Authorization: İstifadəçi icazələrinin idarə edilməsi

Versioning Strategiyaları​

  • URL Versioning: Versiya URI-də göstərilir (/v1/users, /v2/users)
  • Header Versioning: HTTP header-də versiya məlumatı
  • Query Parameter: Sorğu parametri kimi versiya
  • Geriyə uyğunluq: Köhnə versiyaları qorumaq

Sənədləşdirmə​

  • Diagram as Code: API dizaynını kod şəklində yaratmaq (Swagger/OpenAPI, AsyncAPI)
  • Interactive Docs: İstifadəçilərin test edə biləcəyi sənədlər
  • Code Examples: Müxtəlif dillər üçün nümunələr
  • Changelog: Dəyişikliklərin təfərrüatlı tarixçəsi

Əsas Problemlər​

  • Over-fetching: Lazım olmayan məlumatın alınması → GraphQL və ya field selection işlət
  • Under-fetching: Çox sorğu lazım olan hallar → Data aggregation və batch operations
  • Breaking Changes: API dəyişiklikləri mövcud client-ları pozur → Versioning strategiyası
  • Poor Documentation: Zəif sənədləşdirmə → Avtomatik sənəd generatoru işlət
  • Security Issues: Təhlükəsizlik zəiflikləri → OWASP API Security Guidelines
graph TB
    Client[Client Applications] --> Gateway[API Gateway]
    
    Gateway --> Auth{Authentication}
    Auth -->|Authorized| Route[Request Routing]
    Auth -->|Unauthorized| Block[Block Request]
    
    Route --> RL{Rate Limiting}
    RL -->|Within Limit| Cache{Cache Check}
    RL -->|Exceeded| Throttle[Throttle Response]
    
    Cache -->|Cache Hit| Return1[Return Cached]
    Cache -->|Cache Miss| Services[Microservices]
    
    Services --> Service1[User Service<br/>GET /v1/users]
    Services --> Service2[Order Service<br/>POST /v1/orders]
    Services --> Service3[Payment Service<br/>PUT /v1/payments]
    
    Service1 --> DB1[(Users DB)]
    Service2 --> DB2[(Orders DB)]
    Service3 --> DB3[(Payments DB)]
    
    Gateway --> Monitor[Monitoring & Logging]
    Monitor --> Metrics[Metrics]
    Monitor --> Logs[Logs]
    
    subgraph "API Design Patterns"
        REST[REST API]
        GraphQL[GraphQL]
        gRPC[gRPC]
        WebSocket[WebSocket]
    end
    
    subgraph "Response Formats"
        JSON[JSON]
        XML[XML]
        Binary[Binary]
    end
    
    subgraph "Versioning"
        V1[v1 API]
        V2[v2 API]
        Header[Header-based]
        Query[Query-based]
    end
    
    style Gateway fill:#e1f5fe
    style Auth fill:#f3e5f5
    style Block fill:#ffebee
    style Cache fill:#e8f5e8
    style Monitor fill:#fff3e0