REST API
-
두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스
-
REST(REpresentational State Transfer)
API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처 -
API(Application Programming Interface)
다른 소프트웨어 시스템과의 통신을 위한 규칙 정의 -
RESTful API라고도 함
REST 아키텍처 원칙
Uniform interface
-
균일한 인터페이스를 통해 아키텍처를 단순화하고 분리하여 각 부분이 독립적으로 발전할 수 있도록 함
Uniform interface의 4가지 제약 조건
-
Resource identification in requests
→ 리소스 식별을 위해 균일한 리소스 식별자를 사용해야 함 -
Resource manipulation through representations
→ 클라이언트가 지니고 있는 리소스의 표현은 리소스의 상태를 변경∙삭제하기에 충분한 정보를 지니고 있어야 함
→ 이를 위해 서버는 리소스를 자세히 설명하는 메타데이터를 전송 -
Self-descriptive messages
→ 각 메시지는 그것을 어떻게 처리해야하는지에 대한 충분한 정보를 지니고 있어야 함
→ 이를 위해 서버는 리소스를 적절히 사용하는 방법에 대한 메타데이터을 포함한 명확한 메시지를 전송 -
Hypermedia as the engine of application state (HATEOAS)
→ 서버는 클라이언트가 이용가능한 리소스에 대한 하이퍼링크와 표현을 응답함
→ 클라이언트는 애플리케이션의 구조나 변경에 대한 정보를 하드코딩할 필요가 없음
Client–server decoupling
- 사용자 인터페이스와 데이터 저장 문제를 분리
- 사용자 인터페이스의 이식성이 향항됨
- 서버 구성 요소를 단순화하여 확장성을 개선하고, 더 나아가 각 구성 요소가 독립적으로 발전할 수 있도록 함
Statelessness
Statelessness protocol
→ 세션 정보가 서버에 의해 유지되지 않는 통신 프로토콜- 서버가 이전의 요청과 독립적으로 클라이언트 요청을 완료함
- 세션 정보 보존으로 인한 서버 부하를 제거하여 성능을 향상시킴
Cacheability
- World Wide Web에서와 같이 클라이언트 또는 중개자에 응답 캐싱 지원
- 캐싱을 잘 관리하여 Client-Server의 상호작용을 부분적으로 또는 완전히 제거하면 확장성과 성능을 더욱 향상시킬 수 있음
- RESTful 웹 서비스는 캐시 가능 또는 캐시 불가능으로 정의되는 API 응답을 사용하여 캐싱을 제어함
Layered system architecture
- 서버는 클라이언트 요청을 이행하기 위해 보안, 애플리케이션 및 비즈니스 로직 등 여러 계층으로 RESTful 서비스를 설계할 수 있음
- 로드밸런싱을 활성화하고 공유 캐시를 제공하여 시스템 확장성을 향상시킬 수 있음
- 클라이언트는 일반적으로 자신이 최종 서버에 직접 연결되어 있는지 아니면 중간에 연결되어 있는지 알 수 없음
Code on demand (optional)
- 서버는 실행 가능한 코드를 전송함으로써 일시적으로 클라이언트의 기능을 확장하거나 커스터마이즈할 수 있음
REST 아키텍처 사용의 장점
확장성
-
Statelessness
→ 서버가 과거 클라이언트 요청 정보를 유지할 필요가 없으므로 서버 부하 제거 -
Cacheability
→ Client-Server의 상호작용을 부분적으로 또는 완전히 제거 -
이를 통해 성능을 저하시키는 병목 현상을 제거하고 확장성 지원
유연성
- 완전한 Client-Server 분리를 통해 각 부분이 독립적으로 발전할 수 있도록 함
독립성
- REST API는 사용되는 기술과 독립적임
→ API 설계에 영향을 주지 않고 다양한 프로그래밍 언어로 클라이언트 및 서버 애플리케이션을 모두 작성할 수 있음
REST API 요청/응답
클라이언트 요청 구성요소
고유 리소스 식별자
- 일반적으로 URL(Uniform Resource Locator) 사용
- URL은 리소스의 경로를 지정하며, 요청 엔드포인트라고도 함
HTTP 메서드
-
GET
→ 지정된 URL에 있는 서버 리소스에 액세스 -
POST
→ 요청과 데이터 표현을 포함하여 서버에 데이터 전송
→ 동일 요청을 여러 번 전송하면 동일 리소스가 여러 번 생성됨 -
PUT
→ 서버의 기존 리소스 업데이트
→ 동일 요청을 여러 번 전송해도 결과가 동일함 -
DELETE
→ 서버의 리소스 제거
HTTP 헤더
-
데이터
→ HTTP 메서드가 성공적으로 작동하기 위한 데이터가 포함될 수 있음 -
파라미터
→ 수행해야 할 작업에 대한 자세한 정보를 서버에 제공
서버 응답 구성요소
상태 코드
1xx- 조건부 응답2xx- 성공적으로 처리 완료3xx- 리다이렉션 완료4xx- 클라이언트 오류5xx- 서버 오류
메시지 본문
- 클라이언트 요청 구성요소 중 HTTP 헤더에 포함된 내용을 기반으로 적절한 표현 형식 선택
- 클라이언트는 XML 또는 JSON 형식으로 정보를 요청할 수 있음
헤더
- 응답에 대한 추가 컨텍스트를 제공하고 서버, 인코딩, 날짜 및 컨텐츠 유형 등에 대한 정보를 포함함
REST API 인증 방법
HTTP 인증
기본 인증
- 클라이언트가 요청 헤더에 사용자 이름과 암호를 넣어 전송
- 안전한 전송을 위해 base64로 인코딩
전달자 인증
- 토큰 전달자(bearer)에 대한 액세스 제어를 제공하는 프로세스
- 토큰 - 서버가 로그인 요청에 대한 응답으로 생성하는 암호화된 문자열
- 클라이언트가 요청 헤더에 토큰을 넣어 전송
API 키
- 서버가 고유하게 생성된 값을 최초 클라이언트에 할당
- 클라이언트는 고유 API 키를 사용하여 본인을 인증함
- 클라이언트가 API 키를 전송해야 하므로 네트워트 도난에 취약함
OAuth
- 안전한 로그인 액세스를 보장하기 위해 암호와 토큰을 결합
- 서버는 암호를 먼저 요청한 후, 권한 부여 프로세스를 완료하기 위해 추가 토큰을 요청함
