REST
어떤 자원에 대해 CRUD(Create, Read, Update, Delete) 연산을 수행하기 위해 URI(Resource)로 GET, POST등의 방식
(Method)을 사용하여 요청을 보내며, 요청을 위한 자원은 특정한 형태로 (Representation of Resource)로 표현된다.
1. 자원(Resource)
● 모든 자원에는 고유한 ID가 존재하고, 이 자원은 Server에 존재한다.
● 자원을 구별하는 URI이다.
● Client는 URI를 이용해 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청한다.
2. 행위(Verb)
● HTTP 프로토콜의 Method를 사용합니다.
● HTTP 프로토콜은 GET, POST, PUT, PATCH, DELETE의 Method를 제공합니다.
3. 표현(Representation of Resource)
● Client와 Server가 데이터를 주고받는 형태로 JSON, XML 등이 있다.
● JSON, XML을 통해 데이터를 주고받는 것이 일반적이다.
특징
1. Server-Client(서버-클라이언트 구조)
● 자원이 있는 쪽이 Server, 자원을 요청하는 쪽이 Client가 된다.
- REST Server는 API를 제공하고 비즈니스 로직 처리 및 저장을 책임지고 Client는 사용자 인증이나 context
(세션, 로그인 정보)등을 직접 관리하고 책임진다.
- 역할을 확실히 구분시킴으로써 서로 간의 의존성을 줄입니다.
→ (의문점)Server에서도 세션이나 쿠키를 체크하거나 쿠키 정보를 이용하는데 구분이라고 하기
애매하지 않나?...
2. Stateless(무상태)
● HTTP의 특징과 같음 - Connectionfull 포함
3. Cacheable(캐시 처리 기능)
● 웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용할 수 있다.
즉, HTTP가 가진 강력한 특징 중 하나인 캐싱 기능을 적용할 수 있다.
● 대량의 요청을 효율적으로 처리할 수 있다.
→ (의문점) 이건 Browser의 특징이랑 맞물리는데 Rest만의 확실한 특징이라고 할 수 있나?....
4. Layered System(계층 구조)
● Client는 REST API Server만 호출한다.
● 다중 계층으로 구성될 수 있다.
- 보안, 로드 밸런싱, 암호화 등을 위한 계층을 추가하여 구조를 변경할 수 있다.
→ (의문점) 이것도 기존 Controller에서도 가능하지 않나?
5. Uniform Interface (인터페이스 일관성)
● URI로 지정한 Resource에 대한 요청을 통일되고 한정적으로 수행하는 아키텍쳐 스타일을 의미한다.
● 느슨한 결함 형태를 갖는다.
6. Self-Descriptiveness(자체 표현)
● 요청 메시지만 보고도 쉽게 이해할 수 있는 자체 표현 구조로 되어있습니다.
개인적인 의견
- REST API만의 특징이라고 하기에는 예전 사이트에서도 HTTP자체나 웹 브라우저의 특징을
포함한 것 같다. 결국 RestApi만의 특징은 5번 6번이라고 생각한다. URI를 통해서 자원에 대한 요
청을 통일시키고 자체적인 표현만으로 뭐를 하는지 유추 가능하다는 것이다.
→ 틀릴 수도 있다.
REST API의 설계 규칙(외우자 - 개발할 때마다 보기)
1). URI는 명사를 사용한다.
2). 슬래시( / )로 계층관계를 표현한다.
3). 마지막 문자로 슬래시를 포함하지 않는다.
4). 밑줄(_)을 사용하지 않고, 하이픈(-)을 사용한다.
5) URI는 소문자로만 구성한다.
6) HTTP 응답 상태 코드 사용
7) 파일확장자는 URI에 포함하지 않는다.
결론 : REST API와 RESTful API의 차이는 뭘까!?
- REST의 설계 규칙을 잘 지켜서 설계된 API를 RESTful한 API라고 한다. 즉 REST의 원리를 잘 따르는
시스템을 RESTful이란 용어로 지칭된다.