API
애플리케이션 프로그래밍 인터페이스(API)는 다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙을 정의합니다. 개발자는 다른 애플리케이션이 프로그래밍 방식으로 애플리케이션과 통신할 수 있도록 API를 표시하거나 생성합니다.
웹 API는 클라이언트와 웹 리소스 사이의 게이트웨이라고 생각할 수 있습니다.
REST
REST (Representational State Transfer)는 애플리케이션 개발의 아키텍처 중 하나입니다.
REST는 처음에 인터넷과 같은 복잡한 네트워크에서 통신을 관리하기 위한 지침으로 만들어졌습니다...
(아키텍처: 애플리케이션을 설계, 제작하는 데 사용하는 패턴과 기술의 총칭)
REST는 다음의 구성으로 이루어져 있습니다.
- 자원 (Resource) - URI (URL)
자원은 서버에 존재하는 데이터의 총칭입니다. 모든 자원은 고유의 URI (URL)을 가지며 클라이언트는 이 URI를 지정하여 해당 자원에 대해 CRUD 명령을 수행할 수 있습니다 (/resource/1) - 행위 (Verb) - HTTP METHOD
행위는 클라이언트가 HTTP Method를 이용하여 자원을 조작하는 것을 의미합니다. - 표현 (Representations)
클라이언트가 HTTP Method로 자원을 조작하면 서버가 그에 대한 응답 (JSON, XML)을 보내는 것을 의미합니다.
REST의 특징
- Uniform (일관된 인터페이스)
Uniform Interface는 URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 말합니다. - Stateless (무상태성)
REST는 Stateless의 특성을 가집니다. 작업을 위한 상태정보를 따로 저장하고 관리하지 않습니다. 세션 정보나 쿠키정보를 별도로 저장하고 관리하지 않기 때문에 API 서버는 들어오는 요청만 단순히 처리하면 됩니다. 때문에 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로 구현이 단순해집니다. - Cacheable (캐시 가능)
REST의 가장 큰 특징 중 하나는 HTTP를 그대로 사용하기 때문에 웹의 기본 인프라를 사용할 수 있습니다. 따라서 캐시 기능을 이용해 같은 URI에 대한 반복된 요청을 효율적으로 처리할 수 있습니다. - Self - Descriptiveness (자체 표현 구조)
REST의 또 다른 큰 특징 중 하나는 REST API 메시지만 보고도 이를 쉽게 이해할 수 있는 자체 표현 구조로 되어 있다는 것입니다. - Server - Client Archirecture (서버 - 클라이언트 구조)
REST 서버는 API 제공, 클라이언트는 사용자 인증이나 콘텍스트 (세션, 로그인 정보)등을 직접 관리하는 구조로 각각의 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로 간 의존성이 줄어들게 됩니다. - 계층 구조 (Layered System)
REST 서버는 다중 계층으로 구성될 수 있으며, 클라이언트는 대상 서버와 직접 통신하는지 중간 서버와 통신하는지 알 수 없습니다. 따라서 클라이언트와 서버의 통신 사이에 보안이나 로드 밸런싱등을 위한 중간 계층을 추가할 수 있습니다.
REST의 규칙을 지키면서 만든 API를 REST API 혹은 RESTful API라고 부릅니다.
REST API 설계 시 가장 중요한 항목은 2가지로 요약할 수 있습니다.
첫 번째: URI는 정보의 자원을 표현해야 한다.
두 번째: 자원에 대한 행위는 HTTP Method (GET, POST, PUT, DELETE)로 표현한다.
| CRUD | HTTP Method |
| CREATE | POST |
| READ | GET |
| UPDATE | PUT |
| DELETE | DELETE |
REST API 중심 규칙, 주의점
- URI는 정보의 자원을 표현해야 한다. (동사보다는 명사를 사용. 동사를 사용할 때도 있긴 함)
Get /resource/1 - 자원에 대한 행위는 HTTP Method로 표현
정보를 가져올 때 GET 추가할 때 POST.. - 슬래시 ( / )는 계층 관계를 나타낼 때 사용 (마지막 문자로 사용 X)
- 카멜케이스 등 대신 하이픈 ( - )을 사용. 가독성이 좋음
- 밑줄 ( _ )은 URI에 사용 X (안 보이는 경우가 있음)
- URI 경로에는 소문자가 적합
- 파일 확장자는 URI에 포함 X (Accept header를 사용)
GET / members/soccer/345/photo HTTP/1.1 Host: restapi.example.com Accept: image/jpg
RESTful API 인증 방법
RESTful 웹 서비스는 응답을 보내기 전에 먼저 요청을 인증해야 합니다. 인증은 신원을 확인하는 프로세스입니다.
RESTful 서비스 클라이언트는 신뢰를 구축하기 위해 서버에 자신의 신원을 증명해야 합니다.
HTTP는 REST API를 구현할 때 직접 사용할 수 있는 일부 인증 체계를 정의합니다.
다음은 이러한 체계 중 두 가지입니다.
기본 인증
기본 인증에서 클라이언트는 요청 헤더에 사용자 이름과 암호를 넣어 전송합니다. 안전한 전송을 위해 이 페어를 64자의 세트로 변환하는 인코딩 기술인 base64로 인코딩합니다.
전달자 인증
전달자(bearer) 인증이라는 용어는 토큰 전달자에 대한 액세스 제어를 제공하는 프로세스를 나타냅니다. 일반적으로 전달자 토큰은 서버가 로그인 요청에 대한 응답으로 생성하는 암호화된 문자열입니다. 클라이언트는 리소스에 액세스 하기 위해 요청 헤더에 토큰을 넣어 전송합니다.
API 키
API 키는 REST API 인증을 위한 또 다른 옵션입니다. 이 접근 방식에서 서버는 고유하게 생성된 값을 최초 클라이언트에 할당합니다. 클라이언트는 리소스에 액세스 하려고 할 때마다 고유한 API 키를 사용하여 본인을 검증합니다. API 키의 경우 클라이언트가 이 키를 전송해야 해서 네트워크 도난에 취약하기 때문에 덜 안전합니다.
OAuth
OAuth는 모든 시스템에 대해 매우 안전한 로그인 액세스를 보장하기 위해 암호와 토큰을 결합합니다. 서버는 먼저 암호를 요청한 다음 권한 부여 프로세스를 완료하기 위해 추가 토큰을 요청합니다. 특정 범위와 수명으로 언제든지 토큰을 확인할 수 있습니다.
HTTP 응답 상태 코드
REST 원칙에 따라 서버 응답에 다음과 같은 주요 구성 요소를 포함해야 합니다.
상태 표시줄
상태 표시줄에는 요청 성공 또는 실패를 알리는 3자리 상태 코드가 있습니다. 예를 들어, 2XX 코드는 성공을 나타내고 4XX 및 5XX 코드는 오류를 나타냅니다. 3XX 코드는 URL 리디렉션을 나타냅니다.
다음은 몇 가지 일반적인 상태 코드입니다.
- 200: 일반 성공 응답
- 201: POST 메서드 성공 응답
- 400: 서버가 처리할 수 없는 잘못된 요청
- 404: 리소스를 찾을 수 없음
