API(Application Programming Interface) 설계
API는 소프트웨어 컴포넌트 간 통신을 위한 인터페이스입니다. 정보처리기사에서는 REST API 설계 원칙과 최신 API 기술(GraphQL, gRPC)이 출제됩니다.
REST API 설계 원칙
REST 6가지 제약 조건
- 클라이언트-서버: UI와 데이터 저장 분리
- 무상태(Stateless): 각 요청은 필요한 모든 정보를 포함, 서버는 세션 저장 불필요
- 캐시 가능(Cacheable): 응답에 캐시 가능 여부 표시
- 계층화(Layered System): 클라이언트는 중간 서버(프록시, LB) 존재 여부 모름
- 균일한 인터페이스(Uniform Interface): 자원 식별, 표현을 통한 조작, 자기 서술적 메시지, HATEOAS
- 주문형 코드(Code on Demand): 서버가 클라이언트에 실행 코드 전송 (선택적)
Richardson Maturity Model
- Level 0: HTTP 터널 (단일 URI, 단일 동사)
- Level 1: 리소스 (URI로 자원 식별)
- Level 2: HTTP Verbs (GET/POST/PUT/DELETE 적절히 사용)
- Level 3: Hypermedia Controls (HATEOAS – 링크로 가능한 다음 동작 안내)
REST API 설계 규칙
- URI는 명사로 자원 표현 (동사 사용 금지)
- 계층 구조: /users/{id}/orders/{orderId}
- 복수형 사용: /users (not /user)
- HTTP 메서드로 동작 표현: GET(조회), POST(생성), PUT(전체 수정), PATCH(부분 수정), DELETE(삭제)
GraphQL
Facebook이 개발한 API 쿼리 언어로, 클라이언트가 필요한 데이터를 정확히 지정하여 요청합니다.
REST vs GraphQL
- Over-fetching 해결: GraphQL은 필요한 필드만 선택 → 불필요한 데이터 수신 없음
- Under-fetching 해결: 여러 자원을 단일 쿼리로 조회 (REST는 여러 엔드포인트 호출 필요)
- 단일 엔드포인트: 모든 요청이 /graphql로 집중
- 강력한 타입 시스템: Schema로 API 계약 정의
GraphQL 연산
- Query: 데이터 조회
- Mutation: 데이터 변경
- Subscription: 실시간 데이터 구독
gRPC
Google이 개발한 고성능 RPC 프레임워크입니다.
- Protocol Buffers(protobuf): 이진 직렬화 포맷. JSON보다 빠르고 용량 작음
- HTTP/2 기반: 다중화, 스트리밍, 헤더 압축 지원
- 스트리밍: 단방향/양방향 스트리밍 지원
- 마이크로서비스 내부 통신에 적합
API 버전 관리
- URI 버전: /api/v1/users
- 헤더 버전: Accept: application/vnd.api+json;version=1
- 쿼리 파라미터: /api/users?version=1
시험 핵심 포인트
- REST 무상태: 서버는 클라이언트 세션 저장 안 함
- HATEOAS: 응답에 다음 가능한 동작 링크 포함 (REST Level 3)
- GraphQL 장점: Over-fetching/Under-fetching 해결, 단일 엔드포인트
- gRPC: protobuf + HTTP/2, 마이크로서비스 내부 통신
- PUT: 전체 교체 / PATCH: 부분 수정
마무리
API 설계는 정보처리기사 실기에서도 설계 문제로 출제될 수 있습니다. REST 제약 조건과 HTTP 메서드의 적절한 사용, GraphQL의 특징을 중심으로 학습하세요.