Skip to main content

api-design

Guide for designing and documenting RESTful APIs. Use when asked to design an API, create endpoints, or document an API.

معلومات المصدر

المستودع
microsoft/haste
آخر نشاط في المصدر
١٧ يونيو ٢٠٢٦ في ٢٢:١٩
لغة SKILL.md المكتشفة
الإنجليزية
النجوم
١٠٩
التفرعات
١٩

خيارات التثبيت

يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.

مراجعة ملفات المصدر

اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.

عرض SKILL.md

SKILL.md
تعليمات المصدر · معاينة للقراءة فقط
name
api-design
description
Guide for designing and documenting RESTful APIs. Use when asked to design an API, create endpoints, or document an API.
source
Internal engineering practices, REST API conventions
domain
architecture
level
intermediate
agents
["backend-dev","gis"]
created_date
2026-04-27
last_validated
validated_by
status
draft
# API Design ## Overview Standards and patterns for designing consistent, well-documented RESTful APIs. Covers naming, HTTP methods, error handling, status codes, and documentation requirements. ## Key Concepts ### Naming Conventions - Plural nouns for resources: `/users`, `/orders`, `/products` - Kebab-case for multi-word: `/user-profiles` - Nest related resources: `/users/{id}/orders` - Query params for filtering: `/users?role=admin&active=true` ### HTTP Methods | Method | Purpose | Idempotent | Response | |--------|---------|------------|----------| | GET | Read | Yes | 200 + body | | POST | Create | No | 201 + body + Location | | PUT | Replace | Yes | 200 + body | | PATCH | Partial update | No | 200 + body | | DELETE | Remove | Yes | 204 (no body) | ### Error Response Format ```json { "error": { "code": "VALIDATION_ERROR", "message": "Human-readable description", "details": [ {"field": "email", "message": "Invalid email format"} ] } } ``` ### Status Codes - **200**: Success — **201**: Created — **204**: No content - **400**: Bad request — **401**: Unauthorized — **403**: Forbidden - **404**: Not found — **409**: Conflict — **422**: Unprocessable - **429**: Rate limited — **500**: Internal error ## Decision Framework | Scenario | Method | Path | Status | |----------|--------|------|--------| | List items | GET | /items | 200 | | Get one item | GET | /items/{id} | 200 / 404 | | Create item | POST | /items | 201 | | Full update | PUT | /items/{id} | 200 / 404 | | Partial update | PATCH | /items/{id} | 200 / 404 | | Delete item | DELETE | /items/{id} | 204 / 404 | | Search | GET | /items?q=term | 200 | | Bulk action | POST | /items/batch | 200 / 207 | ## Documentation Requirements Every endpoint must document: 1. HTTP method and path 2. Description 3. Request parameters (path, query, body) with types 4. Response schema with examples 5. Error codes and descriptions 6. Authentication requirements ## Common Pitfalls - **Using verbs in URLs** — Use nouns: `/users` not `/getUsers` - **Inconsistent error format** — Use the same error schema everywhere - **Missing pagination** — Any list endpoint that can grow needs pagination - **No versioning strategy** — Decide early: URL (`/v1/`) or header-based
عرض على GitHub