[Java] REST API에 대하여

목차

REST란 무엇인가?

 1. REST의 목적

 2. REST의 구성요소

 3. REST의 특징

 4. REST의 장단점

 5. REST의 설계규칙/디자인 가이드

 6. REST의 응답코드

---

REST란 무엇인가?

 REST는 Representational State Transfer의 약자로, 자원을 이름으로 구분하여, 자원의 정보를 주고받는 모든 것을 의미한다. 좀 더 기술적으로 표현하자면, 네트워크 상에서 Client와 Server사이의 통신 방식. 또는, HHTP 프로토콜로 데이터를 전달하는 하나의 프레임워크라고 할 수 있다.

 REST는 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한으로 활용 가능하다.

 최근 서비스 및 애플리케이션의 개발 흐름이 멀티 플랫폼/디바이스 시대로 넘어와 다양한 기기와 여러가지 웹 브라우저와의 통신에 대응해야 한다. REST는 이에 대응할 수 있는 분산 하이퍼미디어 시스템에서 운영되는 소프트웨어 아키텍처 스타일이라고 할 수 있다.

• 자원 기반의 구조(ROA, Resource Oriented Architecture) : 모든 자원에 대한 고유 HTTP URI이 존재함
• HTTP URI을 통하여 자원(resource) 명시. HTTP Method를 통하여 자원에 대한 CRUD Operation을 명시하여 자원을 처리.
• CRUD Operation란?    

  CREATE	POST : 리소스 생성
  READ	GET : 리소스 조회
  UPDATE	PUT/PATCH : 리소스 갱신(수정)
  DELETE	DELETE : 리소스 삭제
  HEAD	HEAD 정보 조회

   * PUT과 PATCH의 차이? PUT은 리소스 전체 교체 및 수정 / PATCH는 자원의 일부 수정 및 교체. 예를 들어 DB의 특정 컬럼만 수정하고자 하면 PATCH를 사용하고, 전부 다 수정되어야한다면 PUT을 사용하기를 권고

  ---

그림으로 간결히 표현하자면 이렇다.

---

1. REST의 목적

• 분산시스템 : 하나의 커다란 Application을 기능별로 모듈화할 수 있다. 
• 다양한 Client에 대한 대응 : 위에도 언급했다시피, 최근에는 다양한 브라우저 및 디바이스가 존재함으로써 서버 프로그램은 다수의 클라이언트들과 통신할 수 있게 되었다. 이러한 멀티 플랫폼에 대한 지원을 위하여 Restful API를 이용하여 데이터만 주고받으면 여러 방식의 클라이언트들이 자유롭게 데이터를 이용할 수 있다.

2. REST의 구성요소

• 자원(Resource) : URI
• 행위(Verb) : HTTP Method
• 표현(Representations)

구성요소	내용	표현 방법
자원(Resource)	자원	HTTP URI
행위(Verb)	자원에 대한 행위	HTTP Method
표현(Representations)	자원에 대한 행위 내용	HTTP Message Pay Load

3. REST의 특징

• Server-Client 구조 : 클라이언트, 서버, 리소스로 구성된 아키텍처. 서버는 API만 제공하고, 클라이언트는 사용자 인증이나 컨텍스트(세션 등)를 관리하는 등 역할이 확실히 구분되기 때문에 서로 간의 의존성이 줄어든다. HTTP를 통하여 Reqeust 처리.
• 무상태성/스테이트리스(Statelessness) : 서버는 리퀘스트를 처리하는데에 필요한 어떠한 컨텍스트도 서버의 세션에 담지 않는다. 클라이언트에 대한 세션 정보나 쿠키 정보를 관리하지 않기 때문에, API Server는 들어오는 요청만을 처리하면 되기 때문에 구현이 단순해진다.
• 계층형 구조 : API Server가 다중 계층으로 구성될 수 있다는 의미이다. 클라이언트는 REST API Server만을 호출하는데에 반하여, API Server는 다중 계층으로 구성하여 순수한 비즈니스 로직을 담은 API Server 외에 사용자 인증이나 암호화(SSL) 등의 계층을 추가하여 구조상으로 유연성을 둘 수 있다.
• 캐시 가능 : REST는 HTTP라는 기존 웹 표준을 그대로 사용하기 때문에(반드시 HTTP를 이용하여야하는건 아니지만, 대부분의 REST API는 HTTP를 사용하고 있으며, 사실상 표준이다) 기존 인프라를 그대로 사용할 수 있다. HTTP 프로토콜 기반의 SSL은 물론, 캐싱 기능도 적용할 수 있단 의미이다. 일반적인 시스템에서 대부분의 트랜잭션이 조회성인것을 생각하면, HTTP의 리소스를 캐싱하는 것은 성능 면에서 많은 장점을 가지고 올 수 있다. 이렇게 캐시를 사용하게 되면, 전체적인 네트워크 응답시간과 성능, 서버의 자원 사용률을 향상시킬 수 있다.
• 유니폼 인터페이스 : 특정 언어나 기술에 종속되지 않으며 HTTP 표준 프로토콜을 따르는 모든 플랫폼에서 사용이 가능하다.
• 자체 표현 구조 : REST API 메시지만 보고도 이를 쉽게 이해할 수 있다. JSON을 이용하여 직관적으로 이해 가능하다.

4. REST의 장단점

장점

• HTTP 프로토콜 인프라를 그대로 사용하므로, REST API 사용을 위한 별도의 인프라를 구축할 필요가 없다.
• 서버와 클라이언트의 역할을 명확하게 분리할 수 있다.
• HTTP 표준 프로토콜을 따르는 모든 플랫폼에서 사용 가능하다. 범용성을 보장한다.
• 의도하는 바가 명확하므로, 의도를 쉽게 파악할 수 있다.

단점

• 표준 규약이 없다. 안티패턴을 판단하는 근거인 암묵적인 규칙만이 존재한다. 이는 성공적인 REST API 사례를 근거로 하는데, 구글이나 아마존, 넷플릭스 등의 기업이 표준 역할을 담당하고 있다.
• 위에 언급했다시피, 안티패턴으로 설계될 수 있다. 안티패턴이란, REST API의 특징을 이해하지 않고 REST 목적과 어긋나게 설계한 경우를 말한다. 안티패턴의 예로는, Update, Delete 기능을 POST로 대체하여 사용하는 경우/HTTP Response code를 2-3개만 활용하는 경우 등이 있다.
• 사용할 수 있는 Method가 4가지 밖에 없다. HTTP Method 형태가 제한적이다.
• 구형 브라우저에서는 호환이 되지 않아 지원이 어렵다.

5. REST의 설계규칙/디자인 가이드

REST에서 가장 중요한 규칙 두 가지

• URI은 정보의 자원을 표현한다.
• HTTP Method는 자원에 대한 행위를 표현한다.

5-1. URI은 직관적으로

GET /users

5-2. Resource의 이름은 복수 명사

GET /user (X)
GET /users (O)

5-3. URI에 행위는 포함하지 않는다. 자원에 대한 행위는 Method로 표현한다.

GET이라는 method만으로 충분히 표현이 가능하다.
GET /users/view/:id (X)
GET /users/:id (O)

5-4. 마지막에 / 를 포함하지 않는다.

GET /users/:id/ (X)
GET /users/:id (O)

5-5. 언더바(_) 대신 대쉬(-)를 사용한다. 공백을 제거한다.

GET /users/:id/login-log

5-6. 소문자 사용

5-7. URI에 파일 확장자를 포함하지 않는다.

GET /users/:id/users-photos/apple.jpg (X)
GET /users/:id/users-photos/apple (O)

6. REST의 응답코드

• 200 : 클라이언트 요청 정상수행 (응답에 대한 메시지가 포함)
• 201 : 리소스 생성 요청에 대한 정상처리
• 202 : 리소스 생성 요청이 비동기적으로 처리될 때 사용
• 204 : 클라이언트 요청 정상수행 (응답에 대한 메시지 미포함, 삭제요청 따위에 사용)
• 400 : 클라이언트 요청이 부적절할 때 사용 (부적절한 이유를 응답 Body에 넣어줘야 함)
• 401 : 클라이언트가 인증되지 않은 상태에서 보호된 리소스를 요청할 때 사용
• 403 : 클라이언트가 인증상태와 무관하게 응답하고 싶지 않은 리소스를 요청할 때 사용 (400 사용을 권장)
• 404 : 클라이언트가 요청한 리소스가 존재하지 않을 때 사용
• 405 : 클라이언트가 불가능한 메소드를 사용했을 때

---

References

https://meetup.toast.com/posts/92
https://blog.metafor.kr/165 
https://spoqa.github.io/2012/02/27/rest-introduction.html 
https://node-js.tistory.com/17?category=870301