[서론]
- 내가 공부하려고 모은 자료집
- 작성에 도움을 주신 모든 작성자들에게 재밌는 감사의 말씀드립니다.
[1] REST
REST 소개
- REST(Representational State Transfer) : 웹의 장점을 활용할 수 있는 아키텍처
- API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처
REST 정의
-
REST(Representational State Transfer) 자원을 이름으로 구분하여, 해당 자원의 상태를 주고 받는 모든 것
=> 자원의 표현과 상태(정보) 전달
-
HTTP URL(Uniform Resource Identifier)를 통해 자원(Resource)를 명시하고, HTTP Method(POST, GET, PUT, DELETE, PATCH 등)을 통해 해당 자원(URL)에 대한 CRUD Operation을 적용하는 것
**CRUD Operation
- 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능인
Create, Read, Update, Delete을 묶어서 일컫는 말
- REST 에서 CRUD Operation 동작 예시
Create : 데이터 생성(POST)
Read : 데이터 조회(GET)
Update : 데이터 수정(PUT, PATCH)
Delete : 데이터 삭제(DELETE)
**리소스 표현
- 특정 순간 또는 타임스탬프의 리소스 상태
REST 구성
- 자원(Resource) : URL
: 모든 자원에 고유한 ID가 존재하고 이 자원은 서버에 존재하는데, 자원을 구별하는 아이디가 HTTP URL임.
클라이언트는 URL을 이용해 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 서버에 요청함
- 행위(Verb) : HTTP METHOD
: HTTP 프로토콜의 GET, POST, PUT, DELETE 메서드 사용
- 표현(Representations)
: 클라이언트가 자원의 상태(정보)에 대한 조작을 요청하면 서버가 적절한 응답을 보냄. REST 에서 하나의 자원은 JSON, XML, TEXT, RSS등 여러 형태의 representation으로 나타내질 수 있는데, JSON 혹은 XML로 데이터를 주고 받는 것이 일반적
REST 특징
- Server-Client (서버-클라이언트 구조)
: REST 서버는 API 제공, 클라이언트는 사용자 인증이나 세션,로그인 정보와 같은 컨텍스트를 직접 고나리하는 구조로 역할이 분리되어 서로간 의존성 줄어듦
- Stateless (무상태성)
: 작업을 위한 상태 정보를 따로 저장하고 관리하지 않음
: 세션 정보나 쿠키 정보를 별도로 저장하지 않아 API 서버는 들어오는 요청만 단순히 처리하여 서비스의 자유도가 높아지고 서버에 불필요한 정보를 관리하지 않아 구현이 단순해짐
- Cacheable (캐시 처리 가능)
: HTTP라는 기존 웹표준을 그대로 사용해, 웹에서 사용하는 기존 인프라를 그대로 활용 가능함. HTTP가 가진 캐싱 기능을 적용 가능한데, HTTP 프로토콜 표준에서 사용하는 Last-Modified 태그나 E-Tag를 이용하면 캐싱 구현 가능
- Layered System(계층화)
: REST 서버는 다중 계층으로 구성될 수 있어, 보안/로드 밸런싱/암호화 계층을 추가해 구조상 유연성을 둘 수 있으며 PROXY, Gateway 같은 네트워크 기반의 중간매체 사용 가능
- Uniform interface(인터페이스 일관성)
: URL로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일
REST 장단점
<장점>
- HTTP 프로토콜 인프라를 그대로 사용해 REST API 사용을 위한 별도의 인프라 구축이 필요 없음
- HTTP 프로토콜에서 따르는 모든 플랫폼에서 사용 가능
- Hypermedia API의 기본을 지키면서 범용성 보장
- 서버와 클라이언트의 역할을 명확하게 분리
<단점>
- 표준 자체가 존재하지 않아 정의 필요
- HTTP Method 형태가 제한적
- 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 url 보다 header 정보의 값을 처리해야 해서 전문성이 요구됨
- 구형 브라우저에서 호환이 되지 않아 지원하지 못하는 동작이 있음
[2] REST API
- REST 아키텍처 스타일의 디자인 원칙을 준수하는 API
REST API 디자인 가이드
(1) URL은 정보의 자원을 표현함
(2) 자원에 대한 행위는 HTTP method(GET, POST, PUT, DELETE)
REST API 설계
(1) URL은 동사보다는 명사, 대문자 보다는 소문자 사용
(2) 마지막에 슬래시(/) 포함하지 않음
(3) 언더바(_) 대신 (-) 하이픈 사용
(4) 파일확장자에 url에 포함하지 않음
(5) 행위를 포함하지 않음
**API
- Application Programming Interface(API)는 다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙
- 서로 다른 응용 프로그램 간의 상호작용 및 통신을 허용하는 기능과 규칙을 제공
- 요청과 응답을 통한 애플리케이션 사이를 중재함
REST API 작동 방식
(1) 클라이언트가 서버에 요청을 전송함. 클라이언트가 API 문서에 따라 서버가 이해하는 방식으로 요청 형식 지정
(2) 서버가 클라이언트를 인증하고 해당 요청을 수행할 수 있는 권한이 클라이언트에 있는지 확인
(3) 서버가 요청을 수신하고 내부적으로 처리
(4) 서버가 클라이언트에 응답 반환, 응답에 요청이 성공했는지 여부를 클라이언트에게 알려주는 정보를 포함함. 응답에는 클라이언트가 요청한 모든 정보가 포함됨
[3] RESTful
- REST 원리를 따르는 시스템이나, REST를 사용했다고 해서 모두 RESTful 인 것은 아님
- REST API 의 설계 규칙을 올바르게 지킨 시스템을 RESTful 하다고 말할 수 있으며, CRUD 기능을 POST로 처리하는 API 혹은 URL 규칙을 올바르게 지키지 않은 API는 REST API를 사용했지만 RESTful 하지 못한 시스템이라고 할 수 있음
REST API 인증 방법
-
RESTful 웹 서비스는 응답을 보내기 전에 먼저 요청을 인증하는데, 신원을 확인하는 프로세스이다.
-
Restful API에는 4가지 일반적인 인증 방법이 있음
HTTP 인증:
http는 REST API를 구현할 때 직접 사용할 수 있는 일부 인증 체계를 정의함
(1) 기본 인증 : 클라이언트는 요청 헤더에 사용자 이름과 암호를 넣어 전송함. 안전한 전송을 위해 이 페어를 64자의 세트로 변환하는 인코딩 기술은 base64로 인코딩
(2) 전달자 인증: 전달자(bearer) 인증은 토큰 전달자에 대한 액세스 제어를 제공하는 프로세스. 서버가 로그인 요청에 대한 응답으로 생성하는 암호화된 문자열로, 클라이언트는 리소스에 액세스 하기 위해 요청 헤더에 토큰을 넣어 전송
(3) API 키:
RES API 인증을 위한 다른 옵션으로, 서버에서 고유하게 생선된 값을 최초 클라이언트에게 할당함.
클라이언트는 리소스에 액세스하려고 할 때 마다 고유한 API 키를 통해 본인을 검증함
(4) OAuth :
모든 시스템에 대해 매우 안전한 로그인 액세스를 보장하기 위해 암호와 토큰을 결합함. 특정 범위와 수명으로 언제든지 토큰을 확인 가능함
[4] HTTP
- 잘 설계된 REST API는 URL만 잘 설계된 것이 아닌, 리소스에 대한 응답을 잘 내어주는 것 까지 포함한다.
<상태코드>
200 : 클라이언트의 요청을 정상적으로 수행함
201 : 클라이언트가 어떠한 리소스 생성을 요청, 해당 리소스가 성공적으로 생성됨(POST를 통한 리소스 생성 작업 시)
301 : 클라이언트가 요청한 리소스에 대한 URL이 변경 되었을 때 사용하는 응답
400 : 클라이언트 요청이 부적잘함
401 : 클라이언트가 인증되지 않은 상태에서 보호된 리소스를 요청할때 사용하는 응답
403: 유저 인증상태가 관계없이 응답하고 싶지 않은 리소스를 클라이언트가 요청했을 때 사용
405 : 클라이언트가 요청한 리소스에서 사용 불가능한 Method를 이용했을 때
500 : 서버에 문제가 있을 때 사용함
[참고사이트]