REST, REST API, RESTful

REST, REST API, RESTful

REST

• “Representational State Transfer”의 약자
• 자원을 이름으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미한다.
• 자원(resource)의 표현(representation)에 의한 상태 전달
• 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다.
• 네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나이다.
• HTTP URI를 통해서 자원을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해서 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.
• CRUD Operation
  • Create: 생성(POST)
  • Read: 조회(GET)
  • Update: 수정(PUT)
  • Delete: 삭제(DELETE)

 

REST의 장단점

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

 

• 단점
  • 표준이 존재하지 않는다.
  • HTTP Method 형태가 제한적이다.
  • 구형 브라우저에서 호환이 되지 않아 지원해주지 못하는 동작이 많다.

REST 구성 요소

자원(Resource): URI

• 모든 자원에 고유한 ID가 존재하고, 이 자원은 Server에 존재한다.
• 자원을 구별하는 id는 /orders/order_id/1 와 같은 HTTP URI 이다.
• Client는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청한다.

행위(Verb): HTTP Method

• HTTP 프로토콜의 Method를 사용한다.
• HTTP 프로토콜은 GET, POST, PUT, DELETE와 같은 메서드를 제공한다.

표현(Representation of Resource)

• Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답을 보낸다.
• REST에서 하나의 자원은 JSON, XML, TEXT, RSS등 여러 형태의 Representation으로 나타내어 질 수 있다.
• JSON 혹은 XML을 통해 데이터를 주고 받는 것이 일반적이다.

REST 특징

클라이언트 / 서버 구조

• 클라이언트는 유저와 관련된 처리를, 서버는 REST API를 제공함으로써 각자의 역할이 확실하게 구분되고 일관적인 인터페이스로 분리되어 작동할 수 있게 한다.
• REST Server: API를 제공하고 비즈니스 로직 처리 및 저장을 책임진다.
• Client: 사용자 인증이나 context(세션, 로그인 정보)등을 직접 관리하고 책임진다.
• 서로 간 의존성이 줄어든다.

무상태성(Stateless)

• REST 는 HTTP의 특성을 이용하기 때문에 무상태성을 갖는다.
• 즉 서버에서 어떤 작업을 하기 위해 상태정보를 기억할 필요가 없고 들어온 요청에 대해 처리만 해주면 되기 때문에 구현이 쉽고 단순해진다.

캐시 처리 기능(Cacheable)

• HTTP라는 기존 웹표준을 사용하는 REST의 특징 덕분에 기본 웹에서 사용하는 인프라를 그대로 사용 가능하다.
• 대량의 요청을 효율적으로 처리하기 위해 캐시가 요구된다.
• 캐시 사용을 통해 응답시간이 빨라지고 REST Server 트렌잭션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률을 향상 시킬 수 있다.

자체 표현 구조 (Self - descriptiveness)

• JSON을 이용한 메시지 포멧을 이용하여 직관적으로 이해할 수 있고 REST API 메시지만으로 그 요청이 어떤 행위를 하는지 알 수 있다.

계층화(Layered System)

• 클라이언트와 서버가 분리되어 있기 떄문에 중간에 프록시 서버, 암호화 계층 등 중간매체를 사용할 수 있어 자유도가 높다.

유니폼 인터페이스(Uniform)

• Uniform Interface는 HTTP 표준에만 따른다면 모든 플랫폼에서 사용이 가능하며, URI로 지정한 리소스에 대한 조작을 가능하게 하는 아키텍쳐 스타일을 말한다.
• URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다.
• 즉, 특정 언어나 기술에 종속되지 않는다.

 

REST API

API(Application Programming Interface)

데이터와 기능의 집합을 제공하여 컴퓨터 프로그램간 상호작용을 촉진하며, 서로 정보를 교환 가능하도록 하는 것

 

REST API

• REST기반으로 서비스 API를 구현한 것
• 최근 OpenAPI(누구나 사용할 수 있도록 공개된 API), 마이크로 서비스 등을 제공하는 업체 대부분은 REST API를 제공한다.

 

REST API 설계 기본 규칙

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

 

 

REST API 설계 세부 규칙

• 슬래시 구분자(/)는 계층 관계를 나타태는데 사용한다.
• URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
• 하이픈 (-) 은 URI 가독성을 높이는데 사용한다.
• 밑줄 (-) 은 URI에 사용하지 않는다.
• URI 경로에는 소문자가 적합하다.
• 파일확장자는 URI에 포함하지 않는다.
• 리소스 간에 연관 관계가 있는 경우 /리소스명/리소스ID/관계가 있는 다른 리소스 명 GET:/uers/2/orders (일반적으로 소유의 관계를 표현할 때 사용)
•  
• 응답 상태코드
  • 1xx: 전송 프로토콜 수준의 정보 교환
  • 2xx: 클라이언트 요청이 성공적으로 수행됨
  • 3xx: 클라이언트는 요청을 완료하기 위해 추가적인 행동을 취해야 함
  • 4xx: 클라이언트의 잘못된 요청
  • 5xx: 서버쪽 오류로 인한 상태코드

 

RESTful

• RESTful은 일반적으로 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어이다.
• ‘REST API’를 제공하는 웹 서비스를 ‘RESTful’하다고 할 수 있다.
• RESTful은 REST를 REST답게 쓰기 위한 방법으로, 누군가 공식적으로 발표한 것이 아니다.
• 즉 REST의 원리를 잘 따르는 시스템을 RESTful이란 용어로 지칭한다.

RESTful의 목적

• 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것
• RESTful한 API를 구현하는 근본적인 목적이 성능 향상에 있는 것이 아니라 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것이 주 동기이니, 성능이 중요한 상황에서는 굳이 RESTful한 API를 구현할 필요는 없다.