REST API

REST API

REST 아키텍처 스타일의 설계 원칙을 다르는 API이다. REST란 Representational Sate Transfer로 HTTP URI를 통해 자원을 명시하고 HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD 작업(Create, Read, Update, Delete)을 수행하는 것을 말한다.

 

1) 자원-URI

: 모든 자원은 고유한 URI를 가진다. 예를 들어, /users는 사용자 목록에 대한 자원을 의미하며, /users/{id}는 특정 사용자를 식별한다.

2) 행위-HTTP 메서드

- GET: 자원 조회

- POST: 자원 생성

- PUT: 자원 저체 업데이트

- PATCH: 자원의 부분 업데이트

- DELETE: 자원 삭제

3) 표현

: Client가 자원의 상태에 대한 조작을 요청하면 Server는 이에 대한 적절한 응답을 보낸다. 

 

등장 배경

웹이 빠르게 확산되면서 다양한 애플리케이션이 HTTP를 통해 데이터를 주고받기 시작했고, HTTP는 Client-Server 모델을 기반으로 다양한 종류의 자원들을 URI를 통해 정의할 수 있었고, REST는 이를 보다 일관성 있게 활용하는 방식으로 등장했다. REST는 HTTP를 활용하여 CRUD 작업을 단순화하고, 자원을 URI로 통합해 관리할 수 있도록 한다. 즉, 하나의 브라우저뿐만 아니라 웹, 아이폰, 안드로이드 애플리케이션 등과의 통신에 범용적으로 대응하기 위해서 등작하였다.

 

특징

 

• 무상태성 (Stateless)
  서버는 클라이언트의 상태를 저장하지 않으며, 각 요청은 독립적으로 처리됩니다. 따라서 모든 요청에 필요한 정보는 요청에 포함되어야 합니다.
• 캐시 가능성 (Cacheable)
  RESTful API는 웹 표준인 HTTP를 사용하기 때문에, 클라이언트는 서버로부터 받은 응답을 캐시할 수 있습니다. 이로 인해 불필요한 요청을 줄이고 성능을 향상시킬 수 있습니다.
• 일관된 인터페이스 (Uniform Interface)
  RESTful API는 특정 URI와 HTTP 메서드를 사용해 자원에 접근하는 표준화된 인터페이스를 제공하므로, REST 원칙을 따르는 한 특정 API가 다른 API와도 일관된 방식으로 작동합니다.
• 계층화된 시스템 (Layered System)
  클라이언트는 중간 서버를 거쳐 요청을 처리할 수 있으며, 각 서버는 계층적으로 배치되어 독립적으로 작동합니다.

 

중심 규칙
REST에서 가장 중요하며 기본적인 규칙은 아래 두 가지다.

- URI는 정보의 자원을 표현해야 한다.
- 자원에 대한 행위는 HTTP Method (GET, POST, PUT, DELETE 등)으로 표현한다.

세부 규칙
1. 슬래시 구분자 ( / )는 계층 관계를 나타내는데 사용한다.
2. URI 마지막 문자로 슬래시 ( / )를 포함하지 않는다.
즉 URI에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 하며 URI가 다르다는 것은 리소스가 다르다는 것
역으로 리소스가 다르면 URI도 달라져야 한다.
3. 하이픈 ( - )은 URI 가독성을 높이는데 사용한다.
4. 밑줄 ( _ )은 URI에 사용하지 않는다.
5. URI 경로에는 소문자가 적합하다.
URI 경로에 대문자 사용은 피하도록 한다.
6. 파일확장자는 URI에 포함하지 않는다.
REST API 에서는 메시지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URI 안에 포함시키지 않는다.
7. 리소스 간에 연관 관계가 있는 경우
/리소스명/리소스ID/관계가 있는 다른 리소스 명
ex) GET: /users/2/orders (일반적으로 소유의 관계를 표현할 때 사용)