REST 란?

웹 어플리케이션을 개발하기 위한 아키텍쳐 스타일 중 하나로 클라이언트와 서버 간의 통신 방식을 규정한 것입니다. 해당 통신 방식은 HTTP 프로토콜을 기반으로 하며 자원 , 행위 , 표현 세 가지 요소로 구성됩니다.

다시 말해 REST 는 어떤 자원에 대해 CRUD ( Create , Read , Update , Delete ) 를 수행하기 위해 자원 ( Resource ) 와 행위 ( Method ) , 표현 ( Representation of Resource ) 로 구성하여 요청합니다.

REST API 란?

REST 아키텍처 스타일에 따라 구성된 API를 의미합니다.

REST API 는 Resource ( 자원 ) , Method ( 행위 ) , Representation of Reousrce ( 자원의 형태 ) 로 구성됩니다.

RESTful API 란?

REST의 원칙을 따라 웹 서비스를 구현하는 방식을 RESTful API 라고 합니다.

예시로 게시글 작성을 위해 http://localhost:8080/board 라는 URI 를 서버에 요청합니다. 이 때 요청을 위한 Resource ( 자원 , URI ) 와 이에 대한 Method ( 행위 , GET 또는 POST 등 ) , Representation of Resource( 자원의 형태 , JSON ) 을 사용하면 표현이 명확하므로 이를 REST 라고 하고, 이러한 규칙을 지켜서 설계된 API를 REST API 혹은 RESTful API 라고 합니다.

REST API 와 RESTful API의 차이

REST API는 REST 아키텍쳐 스타일을 따르는 API 이며 RESTful API 는 REST API를 제공하는 웹 서비스를 의미합니다. 결국 RESTful API는 REST API의 원칙을 따르기 때문에 REST API 보다는 좀 더 RESTful 하다라고 할 수 있습니다.

RESTful 하다 의미는?

REST API의 원칙을 따라 구성한 웹 서비스를 의미하며, 자원을 URI로 표현하고, Method를 이용해 해당 자원에 대해 CRUD 작업을 수행하며 리소스와 행위를 명시적으로 분리하여 사용하기 때문에 URI만 보고서 어떤 동작을 수행하는지 알 수 있게 구성한 것을 의미합니다.

RESTful API 구성 요소

• Resource
  서버의 존재하는 Resource ( 데이터나 정보 )는 유일한 ID 를 가지고 있으며, 클라이언트는 서버의 Resource 를 요청합니다. 이러한 Resource를 URI라 합니다.
  URI는 정보의 자원을 표현해야 합니다.

• Method
  서버에 요청을 보내기 위한 방식으로 GET , POST , PUT , PATCH , DELETE가 있습니다.

• Representation of Resource
  클라이언트와 서버가 데이터를 주고받는 형태로 json , xml , test , rss 등이 있으며 최근에는 json을 주로 사용합니다.

URI 과 URL의 차이점

URL은 Uniform Resource Locator 의 약자로 인터넷 상 자원의 위치를 의미합니다. 자원의 위치는 어떤 파일의 위치를 의미합니다. 반면에 URI 는 Uniform Resource Identifier로 인터넷 상의 자원을 식별하기 위한 문자열의 구성으로 , URI는 URL를 포함합니다.

REST의 조건 및 특징

RESTful API가 되기 위한 REST 아키텍쳐의 특징은 다음과 같습니다.

Uniform Interface ( 일관된 인터페이스 )

Resource ( URI ) 에 대한 요청이 통일되고 요청을 하는 Client의 플랫폼 ( Android , Ios , Web 등 ) 이 무관하며 , 특정 언어나 기술에 종속받지 않는 특징을 의미합니다. 이러한 특징 덕분에 REST API는 HTTP를 사용하는 모든 플랫폼에서 요청이 가능하며 Loosely Coupling ( 느슨한 결함 ) 형태를 갖고 있습니다.

Stateless ( 무상태성 )

서버는 각각의 요청을 별개의 것으로 처리해야하며, 이전 요청이 다음 요청에 연관되어서는 안됩니다. 그래서 REST API 는 세션정보나 쿠키정보를 활용한 상태 정보를 저장 및 관리하지 않습니다. 이런 특징때문에 REST API는 서비스의 자유도가 높으며, 서버에서 불필요한 정보를 관리하지 않으므로 구현이 단순합니다. 이런 무상태성은 서버의 처리방식에 일관성을 부여하고, 서버의 부담을 줄여줍니다.

Cacheable ( 캐시 기능 )

REST API는 HTTP라는 기존의 웹표준을 사용하기 때문에 웹의 기존 인프라를 활용할 수 있습니다. 그래서 REST API에서도 캐싱 기능을 적용할 수 있는데, HTTP 프로토콜 표준에 사용되는 Last-Modified Tag 또는 E-Tag 를 이용해 캐싱을 구현할 수 있으며, 이것은 대량의 요청을 효율적으로 처리할 수 있습니다.

Client-Server Architecture ( 서버 - 클라이언트 구조 )

REST API에서 자원을 가지는 쪽이 서버 , 자원을 요청하는 쪽이 클라이언트에 해당합니다. 서버와 클라이언트를 독립성을 유지하며 역할을 확실히 구분하여 서로 간의 의존성을 줄입니다.

• REST Server : API를 제공하고 비즈니스 로직을 처리합니다.
• Client : 사용자 인증이나 Context ( 세션 , 로그인 정보 ) 를 직접 관리하고 책임집니다.

Self-Descriptiveness ( 자체 표현 )

REST API는 JSON 메세지만 보고 이를 쉽게 이해할 수 있는 자체 표현 구조로 되어있습니다. JSON 형태의 표현와 URI , Method 를 이용해 무슨 자원을 요청하는지 손쉽게 이해할 수 있어야합니다.

Layered System ( 계층 구조 )

REST API의 서버는 다중 계층으로 구성될 수 있으며 보안 , 로드 밸런싱 , 암호화 등을 위한 계층을 추가하여 구조를 변경할 수 있습니다. 또한 Proxy와 GateWay 같은 네트워크 기반의 중간매체를 사용할 수 있습니다. 하지만 클라이언트는 서버와 직접 통신하는지 중간 서버와 통신하는지 알 수 없습니다.

REST의 설계 규칙

• URI는 명사를 사용합니다.
• URI는 행위에 대한 표현을 쓰지 않습니다.
• 리소스에 대한 행위는 HTTP Method 로 표현합니다. ( GET , POST , PUT 등.. )
• 슬래시로 계층 관계를 표현합니다.
• URI의 마지막에는 슬래시를 붙이지 않습니다.
• URI는 소문자로만 구성합니다.
• 가독성이 떨어지면 하이픈( - )을 사용합니다. ( 긴 URI 경로에 사용합니다. )
• 언더바 ( _ ) 는 사용하지 않습니다. ( 보기 어렵거나 밑줄에 의해 가려질 수 있습니다. )
• 파일 확장자는 URI에 포함하지 않습니다. ( 대신 Accept header 를 사용합니다. )
• 리소스 간에 연관 관계가 있는 경우 리소스 사이에 관계를 표현합니다.
  예시 >
  /리소스명/리소스ID/관계가 있는 다른 리소스 명
  ex) GET: /users/2/orders (일반적으로 소유의 관계를 표현할 때 사용)

REST의 단점

• REST는 point-to-point 통신모델을 기본으로 한다. 따라서 서버와 클라이언트가 연결을 맺고 상호작용해야하는 어플리케이션의 개발에는 적당하지 않다.
• REST는 URI, HTTP 이용한 아키텍처링 방법에 대한 내용만을 담고 있다. 보안과 통신규약 정책 같은 것은 전혀다루지 않는다. 따라서 개발자는 통신과 정책에 대한 설계와 구현을 도맡아서 진행해야 한다.
• HTTP에 상당히 의존적이다. REST는 설계 원리이기 때문에 HTTP와는 상관없이 다른 프로토콜에서도 구현할 수 있기는 하지만 자연스러운 개발이 힘들다. 다만 REST를 사용하는 이유가 대부분의 서비스가 웹으로 통합되는 상황이기에 큰 단점이 아니게 되었다.
• CRUD 4가지 메소드만 제공한다. 대부분의 일들을 처리할 수 있지만, 4가지 메소드 만으로 처리하기엔 모호한 표현이 있다.

Resource 간의 관계 표현

문서 ( Document )

하나의 문서 혹은 객체라고 보며 , 리소스라고 표현할 수 있으며 URI에 표현합니다.
예시로는 /item/30 , /files/member 에 해당됩니다.

컬렉션 ( Collection )

문서 , 객체들의 집합으로 , 복수값을 가집니다. 리소스라고 표현하며 URI에 표현합니다.
예시로는 /members 에 해당합니다.

자원을 표현하는 Collection 과 Document

단수 , 복수를 지켜 컬렉션과 도큐먼트를 사용하면 직관적인 REST API를 설계할 수 있습니다.

예시 - members 안에 students 안에 2014 번의 학생을 가져올 때
http://localhost:8080/members/students/2014

HTTP Method

GET

리소스를 조회할 때 사용합니다. 서버에 전달하고 싶은 데이터는 query ( 파라미터 , 스트링 ) 을 통해서 전달합니다. Body 를 사용하여 전달할 수 있지만 권장하지 않습니다.

POST

새 리소스를 생성할 때 사용합니다. Body를 통해 서버로 요청 데이터를 전달하며 , 단순히 데이터를 변경하거나 생성하는 것을 넘어 프로세스를 처리하는 경우가 해당합니다. POST의 결과로 항상 새로운 리소스가 생성되진 않습니다.
JSON으로 조회 데이터를 넘겨야 하는데 GET 메서드를 사용하기 어려운 경우 등, 다른 메서드로 처리하기 어려울 때 사용합니다.

PUT

리소스를 대체합니다. 리소스가 없는 경우에 생성합니다. 클라이언트가 리소스의 위치를 알고 URI 를 지정하는 것이 POST와의 차이가 있습니다.

PATCH

리소스를 부분적으로 변경할 때 사용합니다. PUT과 달리 변경할 값만 보내면 됩니다.

DELETE

리소스를 삭제할 때 사용합니다.

PUT과 PATCH의 차이점

PUT 메서드는 전체 리소스를 교체하는데 사용되고 , PATCH 메서드는 일부 리소스를 수정하는데 사용됩니다. 전체 리소스를 변경하는 경우는 모든 정보를 완전히 교체하는지 , 일부만 교체하는지 차이가 있습니다. 또한 PUT은 리소스를 일부 변경하는 경우에도 바뀌지 않는 속성을 모두 보내야 합니다.

상태코드

상태 코드	상태 정보	의미
1xx	Informational	요청이 수신되었으며 처리가 계속됩니다.
2xx	Success	요청이 성공적으로 처리되었습니다.
3xx	Redirection	요청이 완료되기 위해 추가 작업이 필요합니다.
4xx	Client Error	클라이언트 오류로 인해 요청이 실패했습니다.
5xx	Server Error	서버 오류로 인해 요청이 실패했습니다.

자주 사용되는 상태 코드

상태 코드	상태 정보	의미
200	OK	요청이 성공적으로 처리되었음을 의미하고, 요청 데이터를 반환합니다.
201	Created	새로운 리소스가 성공적으로 생성되었음을 의미합니다.
204	No Content	요청이 성공되었지만 , 반환할 데이터가 없습니다.
400	Bad Request	클라이언트 요청이 잘못되었음을 의미합니다.
401	Unauthorized	클라이언트가 인증되지 않았음을 의미합니다.
403	Forbidden	클라이언트가 요청한 리소스에 접근할 권한이 없음을 말합니다.
404	Not Found	요청한 리소스를 찾을 수 없습니다.
500	Internal Server Error	서버에서 오류가 발생하여 요청을 처리할 수 없습니다.

참고

참고 블로그 1 : https://mangkyu.tistory.com/46
참고 블로그 2 : https://kmkunk.tistory.com/139
참고 블로그 3 : https://adjh54.tistory.com/150

함께 읽으면 좋은 글

참고 블로그 1 : https://velog.io/@somday/RESTful-API-%EC%9D%B4%EB%9E%80#rest%EC%9D%98-%EA%B5%AC%EC%84%B1
참고 블로그 2 : https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html