[CS]제대로 이해하는 REST API

REST API란 RESTful한 API를 말하며 일련의 특징과 규칙 등을 지키는 API를 일컫습니다.

2000년 Roy Thomas Fielding이 쓴 논문에서 처음으로 등장한 개념입니다. 

 

REST API의 특징

1. Uniform-Interface

API에서 자원들은 각각의 독립적인 인터페이스를 가지며 각각의 자원들이 url 자원식별, 표현을 통한 자원조작, Self-descriptive message, HATEOAS 구조를 가지는 것을 말합니다.

독립적인 인터페이스라는 것은 서로 종속적이지 않은 인터페이스를 말합니다.

예를 들어 웹페이지를 변경했다고 웹 브라우저를 업데이트하는 일은 없어야 하고 HTTP명세나 HTML명세가 변경되어도 웹페이즈는 잘 작동해야 하듯이 말이죠.

 

html 4.0 -> html 5.x

http 1.0 -> 1.1 -> 2 -> 3

발전하지만 웹 브라우저를 업데이트하지 않는다.

 

url 자원식별

idenfitication of resources를 말합니다. 자원은 url로 식별되어야 합니다.

 

표현을 통한 자원조작

manipulation of resources through representations은 url과 GET, DELETE 등 HTTP 표준메서드 등을 통해 자원을 조회, 삭제 등 작업을 설명할 수 있는 정보가 담겨야 하는 것을 말합니다.

 

Self-descriptive message

HTTP Header에 타입을 명시하고 각 메시지(자원)들은 MIME types에 맞춰 표현되어야 합니다. 예를 들어 json을 반환한다면 application/json으로 명시해주어야합니다. MIME types는 문서, 파일 등의 특성과 형식을 나타내는 표준입니다. IETF의 REC6838에 정의 및 표준화되어 있습니다. 'front/ttf', 'text/plain', 'test/csv' 등을 말합니다.

 

예를 들어 json타입의 데이터를 보낼 때는 헤더의 'Content-Type' = 'application/json'을 명시해야 함을 말합니다.  

 

HATEOAS 구조(헤이티오스)

HATEOAS(Hypermedia as the Engine of Application State)는 하이퍼링크에 따라 다른 페이지를 보여줘야 하며 데이터마다 어떤 URL에서 원했는지 명시해주어야 하는 것을 말합니다. 보통은 href, links, link, url 속성 중 하나에 해당 데이터의 URL을 담아서 표기해야 합니다. (_links 속성에 담기도 합니다. 링크를 유추할 수 있는 변수명을 쓰면 됩니다.)

 

ex1)동적으로 링크를 만들며 href 속성을 통해 설정

ex2)link속성을 기반으로 설정

데이터 하나 당 link 한개가 아니라 데이터 여러개 당 link 한개로 걸 수도 있습니다.

2.Staeless

이 규칙은 HTTP자체가 Stateless이기 때문에 HTTP를 이용하는 것만으로도 만족됩니다. 그리고 이는 REST API를 제공해주는 서버는 세션(session)을 해당 서버 쪽에 유지하지 않는다는 의미입니다.

 

3. Cacheable

HTTP는 원래 캐싱이 됩니다. 아무런 로직을 구현하지 않더라도 자동적으로 캐싱이 됩니다. 새로고침을 하면 304가 뜨면서 원래 있던 js와 css이미지 등을 불러오는 것을 볼 수 있습니다.

이는 HTTP 메서드 중 GET에 한정되며 'Cache-Control:max-age=100'(100초)이런 식으로 한정된 시간을 정할 수가 있으며 캐싱된 데이터가 유효한지를 판단하기 위해 'Last-modified'와 'Etag'라는 헤더값을 씁니다. 'Etag'는 전달되는 값에 태그를 붙여서 캐싱되는 자원인지를 확인해주는 것입니다.

 

[참고]HTTP헤더의 Cache-control = no-store로 하게 되면 캐싱이 안됩니다. 기본적으로 cache-control=public으로 되어있기 때문에 캐싱이 되며 HTTP header를 기반으로 캐싱 컨트롤을 하는게 중요합니다.

 

3. Client-Server 구조

클라이언트와 서버가 서로 독립적인 구조를 가져야 합니다. 물론 이는 HTTP를 통해 가능한 구조입니다. 서버에서 HTTP표준만 지킨다면 웹에서는 그에 따른 화면이 잘 나타나게 됩니다. 서버는 그저 API를 제공하고 그 API에 맞는 비즈니스 로직을 처리하면 됩니다. 마찬가지로 클라이언트에서는 HTTP로 받는 로직만 잘 처리하면 되는 것입니다.

 

5. Layered Sysetem

계층구조로 나눠져 있는 아키텍처를 뜻합니다. WEB기반 서비스를 하면 보통 이러한 시스템을 구축하게 됩니다.

REST API의 URL규칙

자원을 표기하는 URL의 아래의 6가지 규칙을 적용해야 합니다.

1. 동작은 HTTP메소드로만 해야 하고 url에 해당 내용이 들어가면 안됩니다. 수정 = put, 삭제 = delete, 추가 = post, 조회 = get을 이용해야 합니다. 예를 들어 'books/delete/1' 이렇게 표기하면 안 된다는 것입니다.

2. .jpg, ,png 등 확장자는 표시 하지 말아야 합니다.

3. 동사가 아닌 명사로만 표기해야 합니다. 유저가 책을 소유한다라는 것을 표현하다면 '유저/유저아이디/inclustion/책/책아이디'로 표현하고 유저가 소유한 아파트를 조회한다고 하면 이렇게 표현해야합니다. /users/{userid}/aparts 또한 /getAllUsers 식의 동사를 집어넣으면 안됩니다.

4. 계층적인 내용을 담고 있어야 합니다. '/집/아파트/전세' 이런 식으로 내려가야 합니다.

5. 대문자가 아닌 소문자로만 쓰며 너무 길 경우에 바를 써야 할 경우 언더바_가 아닌 그냥 -를 씁니다.

6. HTTP 응답 상태코드를 적재적소에 활용합니다. 성공시에는 200, 리다이렌트는 301 등...

 

 

check) 이 글을 읽고 self-descriptive와 hateo에 대해서 설명해보세요.에 대한 대답을 할 수 있어야 합니다.

 

 

https://www.youtube.com/watch?v=7LbylTMlj8M