REST API

REST (Representational State Transfer)

REST란, 자원을 이름으로 구분하고 해당 자원의 상태를 주고 받는 모든 것을 의미한다.

조금 더 자세히 말하자면, HTTP URL을 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD를 적용하는 것을 의미한다.

REST 구성 요소

REST는 자원, 행위, 표현으로 구성되어 있다.

 

1. 자원(Resource) : URL
   자원은 서버에 있는 것으로, DB 안에 들어가 있는 데이터 하나하나를 의미한다.
   클라이언트는 URL를 통해 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 서버에 요청한다.
   
   
2. 행위(Verb) : HTTP Method
   클라이언트는 HTTP Method(POST, GET, PUT, DELETE)를 이용하여 지정한 자원에 대한 조작을 요청한다.
   
   
3. 표현(Representation of Resource)
   클라이언트가 서버에게 자원에 대한 조작을 요청하면 서버는 이에 대한 적절한 응답을 보낸다.
   REST에서 하나의 자원은 JSON, XML, TEXT 등 여러 형태의 응답으로 나타낼 수 있다.

REST가 필요한 이유

최근의 서버 프로그램은 다양한 브라우저와 안드로이드폰, 아이폰과 같은 모바일 디바이스에서도 통신할 수 있어야 한다.

이러한 멀티 플랫폼에 대한 자원을 위해 서비스 자원에 대한 아키텍처를 세우고 이용하는 방법을 모색한 결과, REST에 관심을 가지게 되었다.

REST의 장단점

장점

• HTTP 프로토콜의 인프라를 그대로 사용하기 때문에 REST API 사용을 위한 별도의 인프라를 구축할 필요가 없다.
• HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있다.
• HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
• REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
• 서버와 클라이언트의 역할을 명확하게 분리한다.

단점

• 표준이 존재하지 않는다.
• 사용할 수 있는 메소드가 HTTP Method 4가지 밖에 없다.
• 구현 브라우저가 아직 제대로 지원해주지 못하는 부분이 존재한다.

REST의 기본 원칙 6가지

REST 기본 원칙 6가지를 지키는 것을 RESTful하다고 표현한다.

 

1. 클라이언트-서버 모델
   서버와 클라이언트 역할이 분리되어 독립적으로 교체 및 개발될 수 있다.
   사용자 인터페이스와 데이터 처리 영역이 분리될 수 있어 유지 보수가 매우 쉬워진다
   
   
2. 무상태
   클라이언트의 context를 서버에 저장하지 않는다.
   즉, 세션과 쿠키와 같은 context 정보를 신경쓰지 않아도 되므로 구현이 단순해진다.
   서버는 단순히 요청이 오면 응답을 보내는 역할만 수행하며, 세션 관리는 클라이언트에게 책임이 있다.
   
   
3. 캐시 가능
   REST는 웹 표준인 HTTP를 그래로 사용하므로 웹에서 사용하는 기존 인프라를 그대로 사용할 수 있다.즉, HTTP가 가진 캐싱 기능을 적용할 수 있다. 캐시 사용을 통해 응답시간이 빨라지고 REST 서버 트랜잭션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률을 향상 시킬 수 있다.
   
   
4. 계층화
   클라이언트는 REST API 서버만 호출한다.
   하지만, REST 서버는 다중 계층으로 구성될 수 있으며, 로드 밸런싱, 암호화 계층을 추가하여 구조 상의 유연성을 둘 수 있고 Proxy, 게이트웨이와 같이 네트워크 기반의 중간 매체를 사용할 수 있다. 
   
   
5. 자체 표현 구조
   REST API만 보고도 이를 쉬게 이해할 수 있다.
   
   
6. 인터페이스 일관성
   URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다.
   HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.

REST API 디자인 가이드

1. URI의 자원명은 소문자를 사용하고, 동사보다는 명사를 사용한다.
2. 자원에 대한 행위는 HTTP 메서드를 통해서 표현한다.
3. 하이픈(-)은 URI의 가독성을 위해서 사용한다. 밑줄(_)은 사용하지 않는다.
4. 슬래시 구분자(/)는 계층 관계를 나타낼 때 사용하며, URI의 마지막 문자로는 사용하면 안된다.
5. 파일 확장자는 URI에 포함시키지 않고, Accept header를 사용하여 컨텐츠 타입을 알려준다.

응답 상태 코드

잘 설계된 API는 리소스에 대한 응답을 줘야한다.

• 1XX (정보) : 서버가 요청을 받았으며, 서버에 연결된 클라이언트는 작업을 계속 진행하라는 의미이다.
• 2XX (성공) : 클라이언트의 요청이 성공적으로 수행되었다는 의미이다.
• 3XX (리다이렉션) : 요청 완료를 위해 추가 작업 조치가 필요하다.
• 4XX (클라이언트 오류) : 요청의 문법이 잘못되었거나 요청을 처리 할 수 없다.
• 5XX (서버 오류) : 서버가 명백히 유효한 요청에 대한 충족을 실패했다.