REST

REST(Representational State Transfer) - 자원의 상태 전달

REST는 2000년에 로이 필딩의 논문에서 소개된 것으로, 네트워크를 기반으로 하는 소프트웨어 아키텍처의 한 형식이다. 자원을 정의하고 해당 자원의 정보를 주고 받는 모든 것을 의미한다.

HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method를 통해 자원에 대한 CRUD Operation을 적용하는 것

• CRUD Operation
  • Create : 생성 (POST)
  • Read : 조회 (GET)
  • Update : 수정 (PUT)
  • Delete : 삭제 (DELETE)

REST의 장점

1. HTTP의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구축할 필요가 없다.
2. HTTP의 표준에 따르는 모든 플랫폼에서 사용이 가능하다.
3. 하이퍼미디어 API의 기본을 충실히 지키면서 범용성을 보장한다.
4. REST API 메세지가 의도하는 바를 명확하게 나타내므로 쉽게 파악할 수 있다.
5. 서비스 디자인에서 생기는 여러가지 문제를 최소화한다.
6. 서버와 클라이언트의 역할을 명확하게 분리한다.

REST 구성 요소

• 자원(Resource): URI
  • 모든 자원에 고유한 ID가 존재하고, 이 자원은 Server에 존재한다.
    자원을 구별하는 ID는 ‘/groups/:group_id’와 같은 HTTP URI 다.
    Client는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청한다.
• 행위(Verb): HTTP Method
  • HTTP 프로토콜의 Method를 사용한다.
    HTTP 프로토콜은 GET, POST, PUT, DELETE 와 같은 메서드를 제공한다.
• 표현(Representation of Resource)
  • Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답(Representation)을 보낸다.
    REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타내어 질 수 있다.
    JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다.

REST에 적용되는 6가지 조건

1. 인터페이스 일관성
   인터페이스의 일관성을 지키고 아키텍처를 단순화시켜 작은 단위로 분리하여 클라이언트, 서버가 독립적으로 개선될 수 있어야 한다.
   REST를 처음으로 제시한 Roy Fielding은 이를 "REST 아키텍처 스타일을 다른 네트워크 기반 스타일과 차별하는 핵심적인 기능"이라고 설명한다.
2. Stateless(무상태)
   요청에 대해서 클라이언트의 상태를 서버에 저장하지 않는다.
   각 API 서버는 클라이언트의 요청만을 단순 처리하며 이전의 요청이 다음의 요청 처리에 연관되면 안된다. 하지만 이전 요청으로 인해 DB가 수정되어 DB에 의해 바뀌는 것은 상관없다.
3. Cacheable(캐시 처리 가능)
   HTTP를 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 활용, 클라이언트는 서버의 응답을 캐싱할 수 있어야 한다.
   캐시 사용을 통해 응답시간이 빨라지고 REST 서버 트랜잭션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률을 향상시킬 수 있다.
4. Layered System(계층화)
   서버와 클라이언트 사이에 방화벽, 게이트웨이, Proxy 등 다양한 계층형태로 구성이 가능해야 하며, 이를 확장 할 수 있어야 한다.
5. Code on Demand (Optional)
   자바 애플릿, 자바스크립트, 플래시 등 특정한 기능을 서버로부터 클라이언트가 전달받아 코드를 실행할 수 있어야 한다. 단, 가시성이 감소할 수 있으므로 이는 선택적 가이드라인이다.
6. Server-Client(서버-클라이언트 구조)
   서버와 클라이언트는 서로 독립적으로 분리되어 있어야 한다.
   서버는 API제공, 비즈니스 로직 처리 및 저장을 책임지고 클라이언트는 사용자 인증이나 세션, 로그인 정보 등을 직접 관리하고 책임을 져 서로 간의 의존성이 줄어든다.

인터페이스의 일관성

다음의 항목들이 잘 지켜졌는지에 따라 RESTFul한 지 판단할 수 있다.

• 자원의 식별
  • 자원 그 자체는 클라이언트가 받는 문서와는 개념적으로 분리되어 있다.
    • 예를 들어, 서버는 데이터베이스 내부의 자료를 직접 전송하는 대신, 데이터베이스 레코드를 HTML,XML 혹은 JSON 등의 형식으로 전송한다.
  • 웹 기반의 REST에서는 리소스 접근을 할 때 URI를 사용한다.
    • https:// foo.co.kr/user/100
    • Resource : user
    • 식별자 : 100
• 메세지를 통한 리소스 조작
  • Web에서는 다양한 방식으로 데이터를 전달할 수 있다.
  • 가장 많이 사용되는 방식은 HTML, XML, JSON, TEXT 등
  • 어떠한 타입의 데이터인지 알려주기 위해 HTTP Header 부분에 content-type을 통해서 데이터의 타입을 지정해 줄 수 있다. 또한 리소스 조작을 위해서 데이터 전체를 전달하지 않고 메세지로 전달한다.
    • 서버의 user라는 정보의 전화번호를 처음에는 number라고 결정하고 이 정보를 Client와 주고 받을 때 그대로 사용하고 있었다면 후에 서버의 resourse 변경으로 phone-number로 바뀌게 된다면 Client는 처리하지 못 하고 에러가 난다.
    • 이러한 부분을 방지하기 위하여 별도의 메세지의 형태로 데이터를 주고 받으며 client와 server가 독립적으로 확장 가능하도록 한다.
• 자기 서술적 메세지
  • 요청하는 데이터가 어떻게 처리 되어져야 하는지 충분한 데이터를 포함할 수 있어야 한다.
  • HTTP 기반의 REST에서는 HTTP Method와 Header 정보 그리고 URI의 포함되는 정보로 표현할 수 있다.
    • GET : https://foo.co.kr/user/100 사용자의 정보 요청
    • POST : https://foo.co.kr/user 사용자의 정보 생성
    • PUT : https://foo.co.kr/user 사용자 정보 생성 및 수정
    • DELETE : https://foo.co.kr/user/100 사용자 정보 삭제
  • 그 외 담지 못 한 정보들은 URI의 메세지를 통하여 표현한다.
• 애플리케이션 상태에 대한 엔진으로서 하이퍼미디어
  • REST API를 개발할 때 단순히 Client 요청에 대한 데이터만 응답해주는 것이 아닌 관련된 리소스에 대한 Link 정보까지 같이 포함되어져야 한다.

REST API

REST 기반으로 서비스 API를 구현한 것으로 시스템을 분산해 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 할 수 있다. REST는 HTTP 표준을 기반으로 구현하므로 HTTP를 지원하는 프로그래밍 언어로 클라이언트, 서버를 구현할 수 있다.

Method

기본적으로 사용되는 메서드의 표이다.

메서드	안전성	멱등성	요청 시 바디	설명
GET	○	○	X	데이터 취득
POST	X	X	○	데이터 신규 작성
PUT	X	○	○	데이터 갱신(리소스가 이미 있을때)
DELETE	X	○	X	리소스 삭제
PATCH	X	X	○	차이에 따른 데이터 갱신(리소스가 이미 있을때)
HEAD	○	○	X	GET 메서드에서 바디를 뺀 것
OPTHONS	○	○	X	사용할 수 있는 메서드 목록. CORS에서 사용된다.

URI 설계 원칙(RFC3986)

• 슬래시 구분자 /는 계층 관계를 나타내는데 사용한다.
• URI 마지막 문자로 /는 포함하지 않는다.
• 하이픈 -은 URI 가독성을 높이는데 사용한다.
• 밑줄 _은 사용하지 않는다.
• URI 경로에는 소문자가 적합하다.
• URI에 파일 확장자는 포함하지 않는다.
• 프로그래밍 언어에 의존적인 확장자를 사용하지 않는다.
• 구현에 의존적인 경로를 사용하지 않는다.
• 세션 ID를 포함하지 않는다.
• 프로그래밍 언어의 Method명을 이용하지 않는다.
• 명사에 단수형보다는 복수형을 사용해야한다. 특히 컬렉션에 대한 표현은 복수로 사용
  
• 컨트롤러 이름으로는 동사나 동사구를 사용한다.
• 경로 부분 중 변하는 부분은 유일한 값으로 대체한다.
• CRUD 기능을 나타내는 것은 URI에 사용하지 않는다.
• URI Query Parameter 디자인
  • URI 쿼리 부분으로 컬렉션 결과에 대해서 필터링 할 수 있다.
• URI 쿼리는 컬렉션의 결과를 페이지로 구분하여 나타내는데 사용한다.
• API에 있어서 서브 도메인은 일관성있게 사용해야한다.
• 클라이언트 개발자 포탈 서브 도메인은 일관성있게 만든다.

참고 : 응답 상태 코드

	의미	내용
1XX	처리중	처리가 계속되고 있는 상태. 클라이언트는 요청을 계속하거나 서버의 지시에 따라서 재요청
2XX	성공	요청의 성공
3XX	리다이렉트	다른 리소스로 리다이렉트. 해당 코드를 받았을 땐 Response의 새로운 주소로 다시 요청
4XX	클라이언트 에러	클라이언트의 요청에 에러가 있는 상태. 재전송하여도 에러가 해결되지 않는다.
5XX	서버 에러	서버 처리중 에러가 발생한 상태. 재전송시 에러가 해결되었을 수도 있다.

---

https://ko.wikipedia.org/wiki/REST
https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html