REST API란?

REST는 HTTP 메소드를 기반으로 클라이언트가 서버의 리소스에 접근하는 방식을 규정하는 아키텍쳐

REST API는 REST를 기반으로 서비스를 구현한 API

 

 

1. REST API의 구성

 

 

구성요소	내용	표현방법
자원(리소스)	자원	URI
행위	자원에 대한 행위	HTTP 요청 메소드
표현	자원에 대한 행위의 구체적인 내용	페이로드

 

2. REST API의 설계 원칙

 

URI는 1) 리소스를 표현하는데 집중하고,

행위에 대한 정의는 HTTP 메소드를 통해 하는 것

 

3. URI와 URL

 

1) URI

Uniform Resource Identifier

통합 자원 식별자라는 의미

인터넷 상 Resource의 "자원 자체"를 식별하는 고유 문자열 시퀀스

 

2) URL

Uniform Resource Locator

네트워크 상에서 통합 자원(리소스)의 "위치"를 나타내기 위한 규약

즉, 자원 식별자와 위치를 동시에 보여준다.

 

3) 차이점

URI = 식별자

URI는 scheme, hosts, url-path에 더해 query, bookmark를 포함한다.

 

URL = 식별자 + 위치

URL은 scheme, hosts, url-path까지만 포함한다.

 

i) URL은 일종의 URI이다.

 

 

ii) URL은 프로토콜과 결합한 형태이다.

https://www.elancer.co.kr > URL

어떻게 위치를 찾고 도달가능한지가 포함되어야하기 때문이다.

 

iii) 예시

https://www.elancer.co.kr > URL, URI

https://www.elancer.co.kr/blog/view > URL, URI

https://www.elancer.co.kr/blog/view?seq=40> URI

 

iiii) REST API에서의 URI 규칙

 

1. 소문자 사용

2. 언더바 대신 하이픈 사용

3. URI의 마지막에 슬래시 포함 X

(포함 유무에 따라 다른 리소스에 매핑될 수도 있다)

4. 계층 관계를 나태낼 시, 슬래시 구분자 사용

5. 파일 확장자는 URI에 포함 X

6. 동사보다는 명사 사용

7. URI에 작성되는 영어는 복수형으로 사용

 

 

4. REST API 특징

Client–server 구조 

클라이언트와 서버는 서로 독립적이어야 하며, 클라이언트는 오직 URIs 리소스만 알아야한다.

클라이언트와 서버의 인터페이스가 변경되지 않는 한, 이 둘은 독립적으로 개발되거나 대체될 수 있게 유지해야한다.

(관심사의 명확한 분리)

 

Stateless(무상태성)

클라이언트의 모든 요청에는 해당 요청을 이해할 수 있는 모든 정보가 포함되어야한다.

서버는 HTTP 요청에 대한 어떤 것도 저장하지 않는다.

컨텍스트를 유지해야하는 세션, 인증과 인가에 대한 정보 또한 클라이언트에만 보관되며,

각 요청 시 해당 정보를 모두 포함하여 서버에 요청한다.

 

 

Cacheable

 서버는 Response cache-control 헤더에 해당 요청이 캐싱이 가능한 지에 대한 여부를 제공해야 한다.

이를 제공한다면 클라이언트는 Response를 캐싱하여 서버와 클라이언트 간의 상호작용을 줄이고,

성능과 서버 가용성을 늘릴 수 있다.

 

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

보편적인 소프트웨어 엔지니어링 원칙을 component interface에 적용하면,

전체적인 시스템 아키텍처는 단순화되고 각 상호작용에 대한 가시성이 개선된다.

이름 그대로 일관된 인터페이스를 얻기 위해 REST에서는 4가지 인터페이스 규칙을 정의하였다.

 

identification of resources : 요청 시 개별 자원을 식별할 수 있어야함

manipulation of resources through representations :

어떤 자원에 대헤 작업하기 위한 적절한 표현과 메타데이터를 충분히 갖추고 있다면,

서버는 해당 자원을 변경, 삭제할 수 있는 정보를 가지고 있단 의미

self-descriptive messages : 자신을 어떻게 처리해야하는지 정보를 포함해야함

hypermedia as the engine of application state : 단순히 결과 뿐만이 아니라 결과에 대한 정보를 포함해야 함

 

Layered system(다중 계층)

 REST는 다중 계층 구조를 가질 수 있도록 허용한다.

(예를 들어 API 서버와 DB서버 그리고 인증 서버를 따로 둘 수 있도록).

그리고 각 레이어는 자기와 통신하는 컴포넌트 외 레이어에 대해서는 정보를 얻을 수 없다.

클라이언트는 REST 서버와만 상호작용할 뿐,

REST가 상호작용하는 레이어나 그 외 중간 레이어들,

end server에 직접적으로 요청할 수 없으며 이들의 상호작용 또한 볼 수 없다.

 

Code on demand (optional) 

서버가 클라이언트에서 실행시킬 수 있는 로직을 전송하여 클라이언트의 기능을 확장시킬 수 있다.

이를 통해 클라이언트가 사전에 구현해야하는 기능의 수를 줄여 간소화시킬 수 있다.