-
1. 개요
1) 기존의 웹 서비스 전달 프로토콜인 SOAP는 프로토콜의 처리 중 오버헤드가 발생하는 문제가 존재
2) RESTful: REST 기반의 웹 서비스로 HTTP 기본 기능만으로 원격 정보에 접근하는 응용기술
2. REST (REpresentational State Transfer)
1) HTTP URI를 통해 자원을 명시하고 HTTP method를 통해 해당 자원에 대한 CRUD operation을 적용하는 것
2) 자원 기반 구조로 설계 중심에 리소스가 있고 HTTP method를 통해 리소스를 처리하도록 설계된 아키텍처
3. 구성
1) 자원
(1) 모든 자원에는 고유 ID가 존재하고, 해당 자원은 서버에 존재
(2) 자원을 구별하는 ID는 HTTP URI
(3) 클라이언트는 URI를 이용하여 자원을 지정하고 해당 자원의 정보를 서버에 요청
2) 행위
(1) HTTP 프로토콜의 method를 사용
(2) HTTP 프로토콜은 GET, POST, PUT, DELETE 메서드를 제공함
※ HTTP method
(1) POST : create
(2) GET: read
(3) PUT: update
(4) DELETE: delete
3) 표현
(1) 클라이언트가 자원 정보를 요청하면 서버는 적절한 응답을 전송
(2) XML, JSON 등의 형태로 데이터를 주고 받음
4. 특징
1) CS구조
2) 무상태
(1) HTTP 프로토콜이 무상태 프로토콜이므로 REST도 무상태성
3) 캐시 처리 가능
4) 계층화
(1) 클라이언트는 REST API 서버만 호출
(2) REST 서버는 다중 계층으로 구성될 수 있음
(3) 프록시나 게이트웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있음
5) 인터페이스 일관성
(1) URI로 지정한 리소스에 대한 조작을 통일된 인터페이스로 수행
(2) HTTP 표준 프로토콜을 따르는 플랫폼에서 사용 가능
5. 장, 단점
1) 장점
(1) HTTP 프로토콜의 인프라를 그대로 사용하여 별도의 인프라를 구축할 필요가 없음
(2) HTTP 프로토콜 표준을 최대한 활용할 수 있고 HTTP 표준 프로토콜을 따르는 플랫폼에서 사용 가능
(3) REST API 메시지가 의도하는 바를 명확하게 파악할 수 있어 쉽게 느껴짐
2) 단점
(1) 표준이 없어서 관리가 어려움
(2) 사용할 수 있는 메서드가 4가지로 제한됨
(3) REST에 맞는 설계가 필요
6. REST API
1) 개요
(1) REST 기반으로 API를 구현
(2) open API 및 MSA 등을 제공하는 곳에서는 대부분 REST API를 제공
2) REST API 특징
(1) 유지, 보수 및 운용에 유리: 시스템 분산 및 확장성, 재사용성이 높음
(2) HTTP 표준을 기반으로 구현하므로 HTTP를 지원하는 클라이언트, 서버를 구현
7. REST API 설계
1) 규칙
(1) URI 슬래시 구분자는 계층관계 표현
(2) URI 마지막 문자로 슬래시를 포함하지 않음
(3) 하이픈은 가독성을 높이기 위해 사용
(4) URI 경로는 소문자
2) 응답상태 코드
(1) 100번대: 전송 프로토콜 정보 교환
(2) 200번대: 클라이언트 요청이 성공적으로 수행됨
(3) 300번대: 클라이언트는 요청을 완료하기 위해 추가적인 행동이 필요
(4) 400번대: 클라이언트의 잘못된 요청
(5) 500번대: 서버 오류
8. RESTful
1) REST 원리를 따르는 시스템을 통칭
2) REST를 REST답게 사용하는 것
※ RESTful 하지 않다
(1) CRUD 기능을 모두 POST로 처리하는 API는 RESTful하지 않음
(2) 리소스는 명사적 특성을 갖기에 URL 표기에 동사가 포함되어 있으면 RESTful하지 않음
9. RESTful 목적
1) 성능 목적보다는 API 이해도와 호환성을 높이는 것이 주 목적