REST란? REST API 와 RESTful API

REST란? 

• REST는 REpresentational State Transfer의 약자다.
• 자원을 이름으로 구분하여 해당 자원의 상태(정보)를 주고받는 것을 의미한다.
• 월드 와이드 웹(WWW)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식이다.
• 기본적으로 웹 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용 가능함.

 

REST의 구체적인 개념

•  HTTP URI를 통해 자원을 명시하고, HTTP Method(Get, Post, Put, Delete)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.
• REST는 자원 기반 구조(ROA: Resource Oriented Architecture) 설계 중심에 Resource가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍처. 

 

REST의 구성

• 자원(Resource) - URL
• 행위(Verb) - HTTP Method
• 표현(Representations)

1. 자원(Resource) 

• 모든 자원에는 고유한 ID가 존재하고, 이 자원은 서버에 존재한다.
• 자원을 구별하는 URI는 /members/1 과 같은 URI이다.

 2. 행위(Verb)

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

HTTP 요청 메서드 

 

GET

• 리소스 조회
• 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달

Post

• 요청 데이터 처리, 주로 등록에 사용
• 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.

Put

• 리소스를 대체(리소스가 있다면 대체하고 없다면 생성한다.)
• 클라이언트가 리소스를 식별한다는 것이 중요! -> 클라이언트가 리소스 위치를 알고 URI를 지정한다는 것이 Post와 차이 
• 리소스를 완전히 대체한다.( username과 age에 대한 정보를 가진 리소스에 age만 Put 한다면 기존의 username은 사라짐)

Patch

• 리소스 부분 변경
• Put과 달리 부분만 변경한다.(즉, username과 age에 대한 정보를 가진 리소스에 age만 Patch 한다면 Put과 달리 기존의 username을 가진 채 age에 대한 정보만 바뀐다.)

Delete

• 리소스 제거

HTTP 상태 코드

• 1xx (Informational) : 요청이 수신되어 처리중
• 2xx (Successful) : 요청 정상 처리
• 3xx (Redirection) : 요청을 완료하려면 추가 행동이 필요
• 4xx (Client Error) : 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
• 5xx (Server Error) : 서버 오류, 서버가 정상 요청을 처리하지 못함

3. 표현(Representations of Resource)

• 클라이언트가 정보에 대한 조작을 요청하면 서버는 이에 적절한 응답(Representation)을 보낸다.
• 하나의 자원은 XML, JSON 등 여러 형태로 나타낼 수 있다. 최근에는 JSON으로 주로 주고받는다.

 

REST의 특징 

• 서버 - 클라이언트 구조
• Stateless(무상태성)
• Cacheable(캐시 처리 가능)
• Self - descriptiveness (자체 표현 구조)
• Layered System(계층화)
• Uniform Interface(인터페이스 일관성)

1. 서버 - 클라이언트 구조

• 서버 : API를 제공하고 비즈니스 로직 처리 및 저장을 담당한다.
• 클라이언트 : 사용자 인증이나 context 등을 직접 관리하고 책임진다.
• 서로 간 의존성이 줄어든다.

2. Stateless

• HTTP의 특성을 이용하기 때문에 무상태성이다.
• 상태 정보에 대해 기억할 필요가 없고 요청에 대해 처리만 해주면 되기 때문에 구현이 쉽다.

3. Cacheable

• 기본 웹에서 사용하는 인프라를 그대로 사용할 수 있다.
• 대량의 요청을 효율적으로 처리하기 위해 캐시가 요구된다.
• 캐시 사용으로 응답 시간이 빨라져 전체 응답 시간, 성능, 서버의 자원 이용률을 향상할 수 있다.

4. Self - descriptiveness

• REST API 메시지만으로 그 요청이 어떤 행위를 하는지 알 수 있다.

5. Layered System

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

6. Uniform - interface

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

---

REST API의 정의 

API(Application Programming Interface)란?

→ API는 응용 프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다. (출처 : https://ko.wikipedia.org/wiki/API)

• REST 기반으로 서비스 API를 구현한 것.
• 최근 OpenAPI, 마이크로 서비스를 제공하는 기업 대부분은 REST API를 제공한다.

 

REST API의 등장 

• 하나의 브라우저만 지원하면 됐던 이전과 달리, 여러 웹 브라우저는 물론이고 아이폰, 안드로이드 애플리케이션과의 통신에 대응할 수 있어야 한다.
• 따라서 플랫폼에 맞춰 새로운 서버를 만드는 수고를 들이지 않기 위해 범용적으로 사용성을 보장하는 서버 디자인이 필요하게 되었다.

+ 왜 RESTful API를 만드는 것일까?

• 클라이언트측을 정형화된 플랫폼이 아닌 모바일 , PC , 애플리케이션 등 플랫폼에 제약두지 않는 것을 목표로 하기 때문이다.
• 이전에는 서버측에서 데이터를 전달해주는 클라이언트는 PC 브라우저로 그 대상이 명확했다. 하지만 스마트 기기들이 등장하면서 클라이언트가 다양해졌고 그에 맞춰 일일이 서버를 만드는 것은 비효율적이다.
• 이러한 멀티 플랫폼에 대한 지원을 위해 서비스 아키텍처를 세우고 이용하는 방법을 모색한 결과, RESTful API를 만드는 것이다.

 

REST API의 특징 

• 각 요청이 어떤 동작이나 정보를 위한 것인지를 그 요청의 모습 자체로 추론이 가능한 것이다.

REST API 디자인 유의 사항

• URI는 자원을 표현한다.
• 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.(단, 행위는 URI에 포함하지 않는다.)

 

REST API 설계 규칙

 

1. URI는 명사를 사용한다.(리소스명은 동사가 아닌 명사!)

 

2. 슬래시("/")로 계층 관계를 표현한다.

 

3. 단, URI 마지막 문자로 슬래시("/")를 포함하지 않는다.

 

4. 언더 바("_")를 사용하지 않고, 하이픈("-")을 사용한다.

- 불가피하게 긴 URI를 사용하게 된다면 "하이픈"을 사용해서 가독성을 높인다.

 

5. URI는 소문자로만 구성한다.

 

6. 파일 확장자는 URI에 포함하지 않는다.

Ex) GET /boards/1/star.jpg (X) 

 

그렇다면 RESTful API는 무엇일까??

 

RESTful API 

RESTful API는 REST의 설계 규칙을 잘 지켜서 설계된 API를 의미한다.

즉, REST의 원리를 잘 따르는 시스템을 RESTful이라는 용어로 지칭한다.

 

RESTful은 REST를 REST 답게 잘 쓰기 위한 방법이지 누군가 공식적으로 발표한 것은 아니다.

 

RESTful 하게 만든 API를 보는 것만으로도 어떤 요청을 하는 것인지 파악할 수 있다. 

예를 들어 GET /boards 라는 요청은 게시물 전체를 보여주는 요청이라고 한다면,

POST /boards/1 은 1번이라는 게시물을 생성해주는 URI일 것이다.

GET /boards/1 은 앞에서 생성한 1번 게시물을 상세하게 볼 수 있도록 요청하는 URI일 것이고,

PUT /boards/1 와 DELETE /boards/1 URI는 각각 게시물 내용 수정과 게시물 삭제를 요청하는 의미일 것이다.

 

 

무엇보다 중요한 것은 URI에는 정보의 자원만 표시해야 하며, 자원의 행위는 HTTP Method에 명시한다는 점이다.  

---

※ 도움을 주신 분들

https://dev-coco.tistory.com/97#REST%EC%-D%--%--%EA%B-%-C%EB%--%--

https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

https://velog.io/@somday/RESTful-API-%EC%9D%B4%EB%9E%80#rest-api%EC%9D%98-%EB%93%B1%EC%9E%A5

https://khj93.tistory.com/entry/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-REST-API%EB%9E%80-REST-RESTful%EC%9D%B4%EB%9E%80