REST API : 웹상의 자원에 접근하는 방식을 정의한 아키텍처

REST(REpresentational State Transfer)란?

 - 웹의 장점을 최대화 할 수 있는 아키텍처

 - HTTP 프로토콜 기반으로 웹상의 자원에 접근하는 방식을 정해놓은 아키텍처/인터페이스

 

 

REST의 속성

1. 서버에 있는 모든 Resouce는 각 Resource당 클라이언트가 바로 접근할 수 있는 고유 URI가 존재한다.

2. 모든 요청은 클라이언트가 요청할 때마다 필요한 정보를 주기 때문에 서버에서는 세션 정보를 보관할 필요가 없습니다. 그렇기 때문에 서비스에 자유도가 높아지고 유연한 아키텍처 적응이 가능합니다.

3. HTTP 메소드를 사용한다. 모든 Resource는 일반적으로 HTTP 인터페이스인 GET, POST, PUT, DELETE 4개의 메소드로 접근되어야 한다.

4. 서비스 내에 하나의 Resource가 주변에 연관된 리소스들과 연결되어 표현이 되어야한다.

 

REST의 구성요소

1. Resource

REST에서 자원에 접근할 때는 URI(Uniform Resource Identifier)를 통하게 된다. URI는 자원의 위치를 나타내는 식별자인데, URI를 설계할 때 지켜야할 설계 규칙이 존재한다.

 

(1) 슬래시 구분자(/)는 계층관계를 나타낼 때 사용

 

ex) http://www.happy-zoo/animals/dogs/john 

 

해당 사이트에서 강아지 john 의 정보를 찾을 때 happy-zoo부터 하위 속성들을 거쳐서 john까지 도달하는 구조입니다.

 

(2) 그렇기 때문에 URI 마지막 문자 슬래시(/)를 포함하지 않는다.

URI 를 이루는 RESOURCE들은 동사보다는 명사로 이루어져야 합니다.

자원의 정보를 표현해야 하는 URI는 동사보다 명사로 구성되어야 한다.

 

1 - 1. Resource 간의 관계를 표현하는 방법

REST 리소스 간에는 연관 관계가 있을 수 있고, 이런 경우 다음과 같은 표현 방법으로 사용

 

example.com/리소스명 /리소스 ID/관계가 있는 다른 리소스명

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

 

만약에 관계명이 복잡하다면 이를 서브 리소스에 명시적으로 표현하는 방법이 있습니다. 예를 들어 사용자가 좋아하는 디바이스 목록을 표현해야 할 경우 다음과 같은 형태로 사용될 수 있습니다.

 

GET : /users/{userid}/likes/devices (관계명이 애매하거나 구체적 표현이 필요할 때)

 

2. URI에서는 '_'(언더바)보다는 '-'(하이픈)을 권장합니다.

가독성이 중요한 ‘_’은 resource 해석에 혼란을 줄 수 있기 때문입니다.

 

3.URI 경로에는 소문자가 적합합니다.

URI 경로에 대문자 사용은 피해야 합니다. 대소문자에 따라 다른 리소스로 인식하게 되기 때문입니다.

 

4. 파일확장자는 URI에 포함시키지 않는다.  Accept header를 사용하도록 해야합니다.

GET / members/soccer/345/photo HTTP/1.1 Host: restapi.example.com Accept: image/jpg

 

 

HTTP 메소드

 

End Point

메소드는 같은 URI들에 대해서도 다른 요청을 하게끔 구별해주는 항목이 있습니다. 이것을 Endpoint라고 합니다.

 

Message

메시지는 HTTP 헤더와 바디, 응답상태코드로 구성되어 있으며, 헤더와 바디에 포함된 메시지는 메시지 처리를 위한 충분한 정보를 포함합니다.

 

Body

자원에 대한 정보를 전달 (데이터 포멧: json, xml, 사용자정의포맷)

 

Header

http 바디에 어떤 포멧으로 데이터가 담겼는지 정의합니다

요청 HTTP헤더는 'ACCEPT' 항목으로 데이터 포멧을 설명

응답 HTTP 헤더는 Content-type으로 컨텐츠 타입을 설명

 

 

장점

1. 언어와 플랫폼에 독립적이다.
2. SOAP(다른 통신방식)보다 개발이 쉽고 단순하다.
3. REST가 지원하는 프레임워크나 언어등 도구들이 없어도 구현이 가능하다.
4. 기존 웹 인프라를 사용가능하다. HTTP를 그대로 사용하기 때문에 그런 것이다.

단점

1. HTTP 프로토콜만 사용이 가능하다.
2. p2p 통신 모델을 가정했기 때문에 둘 이상을 대상으로 하는 분산환경엔 유용하지 않다.
3. 보안, 정책등에 대한 표준이 없기 때문에 관리가 어렵고 이러한 부분까지 고려해서 구현 할 경우 설계나 구현에서 좀 더 어려움을 갖는다.