REST
REST(Representational State Transfer)
REST는 인터넷 상에서 클라이언트와 서버간의 통신을 위한 설계원칙과 제약 조건들을 정의함.
REST 구성
- 자원 Resource : URI
모든 자원에 고유한 ID가 존재하고, 이 자원은 서버에 존재함.
자원을 구별하는 ID는 HTTP URI.
클라이언트는 URI를 이용해서 자원을 지정하고, 해당 자원의 상태(정보)에 대한 조작을 서버에 요청함. - 행위 Verb : HTTP METHOD
HTTP METHOD(GET, POST, PUT, DELETTE 등)를 사용함. - 표현 Reprsentations
클라이언트가 자원의 상태(정보)에 대한 조작을 요청하면 서버는 적절한 응답(Representation)을 보냄.
REST 아키텍처에 적용되는 6가지 원칙
- Client-Server Architecture 클라이언트-서버
클라이언트(사용자 인터페이스)와 서버(데이터 저장)가 독립적으로 분리되어 있어야함. - Stateless 무상태성
서버는 클라이언트의 상태를 저장하지 않으므로, 각 요청은 서버가 요청을 이해하고 처리하기 위해 필요한 모든 정보를 포함해야함. - Cacheable 캐시가능
서버의 응답은 캐시 가능 여부를 명시해야함. 적절한 캐싱은 클라이언트-서버간의 반복된 데이터요청을 줄이고 성능을 향상시킬 수 있음 - Layered System 계층화된 시스템
클라이언트는 자신이 직접적으로 연결된 서버이든, 중간에 다른 서버를 거치는 서버이든 상관없이 서버와 상호작용할 수 있음. 계층화는 시스템의 구조를 단순화하고 확장성을 증가시킴. - Code on Demand
선택전 조건. 서버는 실행 가능한 코드를 클라이언트에 전송할 수 있음. 클라이언트의 기능을 일시적으로 확장할 수 있음. - Uniform Interface 인터페이스 일관성
시스템간의 상호작용을 단순화하기 위해 통일된 인터페이스를 유지해야함. 모든 API 요청은 동일하게 보여야함.- Identification of Resource 자원의 식별 : 모든 자원은 고유한 식별자(ex.URI)를 통해 구분되어야함.
- Representation of Resource 자원에 대한 표현 : 클라이언트가 서버로부터 자원의 상태(HTML, XML, JSON 등)를 요청하고, 서버는 이해할 수 있는 형식으로 자원의 상태를 전달해야함
- Self-descriptive Message 자기-기술적 메세지 : 각 메세지는 충분한 정보를 포함해야하므로, 메시지를 받는 쪽에서는 해당 메시지를 어떻게 처리해야할지 알 수 있어야함.
- Hypermedia as the Engine of Application State, HATEOAS : 애플리케이션의 현재상태와 가능한 다음 상태는 하이퍼링크를 통해 제공되어야함.
REST API
REST API는 REST 아키텍처 스타일의 디자인 원칙을 준수하는 API.
REST API는 HTTP 요청을 통해 통신함으로써 리소스 내에서 레코드의 작성, 읽기, 업데이트 및 삭제(CRUD) 등의 표준 데이터베이스 기능을 수행함.
- URI는 정보의 자원을 표현해야함. URI는 자원을 표현하는데 중점을 두어야함. 행위에 대한 표현이 들어가서는 안됨.
- 자원에 대한 행위는 HTTP(GET, POST, PUT, DELETE 등)로 표현
| METHOD | 역할 |
|---|---|
| POST | POST를 통해 해당 URI를 요청하면 리소스를 생성함 |
| GET | GET를 통해 해당 리소스를 조회함. 리소스를 조회하고 해당 도큐먼트에 대한 자세한 정보를 가져옴 |
| PUT | PUT를 통해 해당 리소스를 수정함 |
| DELETE | DELETE를 통해 리소스를 삭제함 |
URI 설계시 주의할 점
- 슬래시 구분자(/)는 계층관계를 나타내는 데 사용
- URI 마지막 문자로 슬래시(/)를 포함하지 않음
- 하이픈(-)은 URI 가독성을 높이는데 사용
- 밑줄(_)은 URI에서 사용하지 않음
- URI 경로에는 소문자가 적합
- 파일확장자는 URI에 포함시키지 않음
HTTP 응답 상태 코드
| 상태코드 | |
|---|---|
| 200 | 클라이언트의 요청을 정상적으로 수행함 |
| 201 | 클라이언트가 POST를 통해 어떠한 리소스 생성을 요청, 해당 리소스가 성공적으로 생성됨 |
| 400 | 클라이언트의 요청이 부적절할 경우 사용하는 응답코드 |
| 401 | 클라이언트가 인증되지 않은 상태에서 보호된 리소스를 요청했을때 사용하는 응답코드 |
| 403 | 유저 인증상태과 관계없이 응답하고 싶지않은 리소스를 클라이언트가 요청했을때 사용하는 응답코드(403보다는 400이나 404를 사용할 것을 권고. 403 자체가 리소스가 존재한다는 뜻이기 때문 |
| 405 | 클라이언트가 요청한 리소스에서는 사용 불가능한 Method를 이용했을 경우 사용하는 응답코드 |
| 301 | 클라이언트가 요청한 리소스에 대한 URI가 변경되었을때 사용하는 응답코드(응답시 Location header에 변경된 URI를 적어줘야함 |
| 500 | 서버에 문제가 있을 경우 사용하는 응답코드 |
RESTful API
RESTful API는 REST원칙들을 엄격하게 준수하는 API
접미사 -ful : 어떤 것이 가득차 있거나 특정한 특성을 가지고 있다는 것을 나타냄.
REST API는 넓은 의미에서 REST 아키텍쳐 원칙을 따르는 모든 종류의 API를 포함할 수 있으며, RESTful API는 REST 아키텍처 원칙을 엄격하게 준수하는 API를 특별히 지칭함. 모든 RESTful API는 REST API이지만, 모든 REST API가 RESTful한것은 아님.
추가로 공부할 부분
