피드로 돌아가기![[EN] How to Organize a REST API Tree to Survive Time (and Org Chart Changes)](/_next/image?url=https%3A%2F%2Ftsewlmecqtvqphyhezcm.supabase.co%2Fstorage%2Fv1%2Fobject%2Fpublic%2Fthumbnails%2F0d303147-00e3-487b-94cd-3d12239ba58b.webp%3F&w=3840&q=75)
Dev.toBackend
원문 읽기
직관 기반 설계 탈피를 위한 6가지 API 분류 체계 도입 및 구조적 일관성 확보
[EN] How to Organize a REST API Tree to Survive Time (and Org Chart Changes)
AI 요약
Context
개발자 개별 직관과 조직도 기반의 API 엔드포인트 설계로 인한 일관성 결여 문제 발생. 중복 엔드포인트 생성 및 프론트엔드-백엔드 간 과도한 호출 횟수 증가로 인한 유지보수 비용 상승.
Technical Solution
- 엔드포인트 설계 전 요구사항의 성격을 규정하는 Pre-design Classification 체계 도입
- Atomic 연산 중심의 Source of Truth를 관리하는 Core Domain (/domain/{resource}) 설계
- 내부 도메인 구조 변화를 소비자로부터 격리하여 결합도를 낮추는 View (/views/{name}) 계층 구축
- 단순 CRUD를 넘어 복잡한 비즈니스 시퀀스 및 배치 작업을 처리하는 Process (/processes/{name}) 분리
- 외부 계약 기반의 인터페이스 관리를 위한 Integration (/integrations) 및 설정/시스템 전용 경로 정의
- 글로벌 버전ing(/api/v1) 정책을 기계적으로 적용하지 않고 각 분류 성격에 맞는 독립적 Versioning 전략 채택
실천 포인트
- 신규 엔드포인트 설계 전 'Atomic 리소스 조작인가' 아니면 '비즈니스 프로세스 실행인가'를 먼저 판별할 것 - 특정 화면을 위한 데이터 조합이 필요할 경우 Core Domain 수정 대신 View 레이어 생성 검토 - 외부 Webhook이나 API 연동 시 내부 API 버전 체계와 분리된 독립적 경로 설계 적용 - 분류 기준이 모호한 경우 가장 구체적이고 제약 사항이 강한 분류를 우선적으로 선택