REST API란?

1. REST (Representational State Transfer) 역사

REST는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식입니다. 이 용어는 HTTP의 주요 저자 중 한 사람인 로이 필딩(Roy Fielding)의 2000년 박사학위 논문에서 소개되어 네트워킹 문화에 널리 퍼졌습니다.

 

웹이 급속도로 성장하는 도중에서 HTTP의 기능을 고쳐야 하는 상황인데, 기존에 구축되어있는 웹과 어떻게 호환성 문제가 생기는걸 피할까 고민을하였고 그 결과로 REST가 나왔습니다. 웹페이지를 변경했다고 웹 브라우저를 업데이트할 필요가 없으며, 웹 브라우저를 업데이트했다고 웹 페이지를 변경할 필요가 없습니다.

 

REST는 네트워크 아키텍처 원리의 모음으로 자원을 정의하고 자원에 대한 주소를 지정하는 방법 전반을 일컫습니다. 필딩의 REST 원리를 따르는 시스템은 종종 RESTful이라는 용어로 지칭됩니다. 

 

REST는 애플리케이션의 분리 및 통합. 다양한 클라이언트의 등장. 최근의 서버 프로그램은 다양한 브라우저 및 스마트폰에서도 통신을 할 수있어야하므로, 멀티 플랫폼 지원을 위해 REST에 대한 관심이 높아지고 있습니다.

2. REST 정의

A way of providing interoperability between computer systems on the Internet.

 

REST란 웹에 존재하는 모든 자원(이미지, 동영상, DB자원)에 고유한 URI를 부여해 자원을 정의하고 해당 자원의 상태(정보)를 주고받는 방법론을 의미

3. REST 구성

• 자원(Resource) - URI

• 행위(Verb) - HTTP Method

• 표현(Representations)

4. REST의 장단점

[장점]

• HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출할 필요가 없다.

• HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해준다.

• HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.

• Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다.

• REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.

• 여러가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.

• 서버와 클라이언트의 역할을 명확하게 분리한다.

[단점]

• 표준이 존재하지 않는다.

• 사용할 수 있는 메소드가 4가지 밖에 없다. HTTP Method 형태가 제한적이다.

• 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 값이 왠지 더 어렵게 느껴진다.

• 구형 브라우저가 아직 제대로 지원해주지 못하는 부분이 존재한다. (PUT, DELETE를 사용하지 못하는 점. pushState를 지원하지 않는 점)

5. REST 아키텍처에 적용되는 6가지 제한 조건

• 클라이언트/서버구조(client-server) : 클라이언트는 유저와 관련된처리, 서버는 REST api를 제공함으로써 각각의 역할이 구분되고 일관적인 인터페이스로 분리되어 작동할 수 있게 합니다. 

• 무상태(Stateless) : HTTP는 Stateless Protocol이므로, REST역시 무상태성을 갖습니다. 즉, HttpSession과 같은 컨텍스트 저장소에 상태정보를 따로 저장하지 않고, API 서버는 들어오는 요청을 단순처리하면 됩니다. 세션과 같은 컨텍스트 정보를 신경쓸 필요가 없어 구현이 단순해집니다.

• 캐시처리가능(Cacheable) : HTTP 기존의 웹 표준을 그대로 사용하므로, 웹에서 사용하는 기존의 인프라를 그대로 활용가능합니다. HTTP 프로토콜 기반의 로드밸런서나 SSL, HTTP가 가진 강력한 특징 중 하나인 캐싱기능을 적용할 수 있습니다.

• 계층화(Layered System) : API 서버는 순수 비즈니스 로직을 수행하고, 그 앞단에 사용자 인증, 암호화(SSL), 로드 밸런싱 등을 하는 계층을 추가하여 구조상의 유연성을 둘 수 있습니다. 

• Code on demand (optional) : 자바 애플릿이나 자바스크립트의 제공을 통해 서버가 클라이언트가 실행시킬 수 있는 로직을 전송하여 기능을 확장 시킬 수 있습니다.

• 인터페이스 일관성(uniform interface) : HTTP 표준에만 따른다면, 안드로이드/IOS 플랫폼이든, 특정 언어나 기술에 종속되지 않고 모든 플랫폼에 사용이 가능하며, URI로 지정한 리소스에 대한 조작이 가능한 아키텍처 스타일을 의미합니다.

[uniform interface의 제약조건]

* identification of resources : 리소스가 URI로 식별되야 합니다.

 

* manipulation of resources through representations : representation 표현을 통해서 resource를 조작해야합니다. HTTP 메세지에 그표현을 담아서 전송을해서 달성합니다.

 

* self-descriptive messages : 메세지가 스스로에 대해서 설명을 합니다. 서버나 클라이언트가 변경되더라도 오고가는 메세지는 언제나 self-descriptive하므로 언제나 해석이가능합니다. 현재 REST API라고 칭하는 대부분이 거의 지키지 못하고 있습니다. 

 

* HATEOAS(hypermedia as the engine of application state) : 애플리케이션의 상태는 Hyperlink를 이용해서 전이되어야합니다. 현재 REST API라고 칭하는 대부분이 거의 지키지 못하고 있습니다. 다음은 HTML과 JSON의 응답결과로 HATEOAS가 만족되는 모습입니다.

json으로도 Link라는 header가 이 리소스와 연결되어있는 다른 리소스를 가르킬 수 있습니다.

6. REST API 설계 방법

URL은 정보의 자원을 표현해야하기 때문에 설계 할때 몇가지 지켜야할 것들이있습니다.

 

1. 소문자를 사용합니다.

 

2. 슬래시 구분자(/)는 계층 관계를 나타내는데 사용합니다.

    - (ex) http://restapi.com/houses/apartments 

 

3. URI 마지막 문자로 슬래시(/)를 포함하지 않습니다.

 

4. 하이픈(-)은 불가피하게 긴 URI경로를 사용할 경우 URI의 가독성을 높이는데 사용합니다.

 

5. 밑줄(_)은 URI에서 사용하지 않습니다.

 

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

 

7. 리소스간에 연관 관계가 있는 경우

    - /리소스명/리로스ID/관계가 있는 다른 리소스명

     (ex) GET : /users/{userId}/devices   (일반적으로 소유 'has'의 관계를 표현할 때)

 

자원에 대한 행위는 HTTP Method로 표현합니다.

HTTP Method	역할
GET	GET을 통해 해당 리소스를 조회합니다.
POST	POST를 통해 해당 URL를 요청하면 리소스를 생성합니다.
PUT	PUT을 통해 해당 리소스를 수정합니다.
DELETE	DELETE를 통해 해당 리소스를 삭제합니다.

 

예를 들어 게시글을 수정하기 위해서 옳은 예시와 틀린 예시는 다음과 같습니다.

POST /posts/put/:id (X)
POST /posts/update/:id (X)

PUT /posts/:id (O)

REFERENCE

https://ko.wikipedia.org/wiki/REST

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

https://velog.io/@wlsdud2194/HTTP-REST-API-%EB%9E%80

https://brainbackdoor.tistory.com/53