[Network] RESTful API에 대해

오늘은 저번에 알아봤던 HTTP 메서드와 연관이 있는 RESTful API에 대해 알아보도록 하겠다!

 

Restful을 알아보기 전에! 미리 REST에 대해 알아보도록 하자!

 

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

 

다시 말해 REST는 어떤 자원에 대해 CRUD (Create, Read, Update, Delete)를 수행하기 위해 자원과 행위, 표현으로 구성하여 요청한다.

 

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

 

REST API는 Resource, Method, Repersentation of Resource로 구성된다.

 

RESTful API란? REST 원칙을 따라 웹 서비스를 구현하는 방식을 의미한다.

 

예시로 이 포스팅을 작성하기 위해 http://localhost:1213/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의 조건 및 특징

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

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

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

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

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

 

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

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

REST의 설계 규칙

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

REST의 단점

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

 

참고

https://mangkyu.tistory.com/46

[Server] Restful API란?

 

함께 읽으면 좋은 글

https://ddevws.tistory.com/entry/HTTP-%EB%A9%94%EC%84%9C%EB%93%9C%EC%99%80-%EC%83%81%ED%83%9C%EC%BD%94%EB%93%9C%EC%97%90-%EB%8C%80%ED%95%B4

[Network] HTTP 메서드와 상태코드에 대해