REST API

REST API? RESTful API?

종종 들어봤지만 헷갈리는 REST API는 도대체 무엇일까?

 

- API

먼저 API가 무엇인지 간단히 짚고 넘어가자.

UI(User Interface)가 사용자와 프로그램간의 연결이라면 API(Application Programming Interface)는 컴퓨터 프로그램간에 정보를 주고받는 방법 혹은 연결이다.

우리는 API를 통해 서로 다른 컴퓨터, 프로그램 사이에서 정보를 주고 받는다. 인터넷으로 버스 노선을 검색하면 우리의 컴퓨터는 버스 노선을 제공하는 서버와 API를 통해서 정보(버스 노선 데이터)를 주고 받는다.

 

그렇다면 REST API란 무엇일까?

REST API는 이러한 API중 REST 구조를 따르는 API라고 한다.

 

 

- REST 배경

REST의 등장 배경을 먼저 알아보자.

1991년에 웹이 등장했다. 웹은 모든 정보를 하이퍼텍스트로 연결하는데 표현형식은 HTML, 식별자는 URI, 전송방법은 HTTP를 사용한다.

웹이 발전하면서 로이필딩(Roy T. Fielding)이라는 사람이 기존의 있는 웹을 건드리지 않고 HTTP를 향상시킬 수 있는 방법을 고민했고 제안한게 REST 이다. REST라는 단어는 그가 2000년에 발표한 박사논문에서 처음 정의되었다.

 

이 REST 구조를 따르는 API, REST API 전에도 API가 존재했지만, 사람들은 REST API의 단순함 때문에 REST API를 사용하기 시작했고 수 많은 사람들이 REST API를 사용하기 시작했다.

 

하지만 정작 REST를 만든 로이필딩은 대부분의 사람들이 REST API를 제대로 쓰고 있지 않다며 꼬짚었다.

 

그래서 정확한 REST API는 무엇일까?

 

 

- REST API

REST API = REST 아키텍쳐 스타일을 따르는 API이다.

REST = 분산 하이퍼미디어 시스템(ex 웹)을 위한 아키텍쳐 스타일

아키텍쳐 스타일 = 제약조건의 집합

 

REST의 아키텍쳐의 제역조건은 총 여섯가지다

1. client - server

   클라이언트와 서버의 각 파트를 분리 독립시킨다.

2. stateless

   클라이언트의 각각의 요청들을 서버에 저장하지 않는다.

3. cache

   클라이언트는 응답을 캐싱할 수 있어야 한다.

4. uniform interface

   일관적인 인터페이스로 분리되어야 한다.

5. layer system

   클라이언트는 보통 대상 서버에 직접 연결되었는지 중간 서버를 통해 연결되었는지 알 수 없다.

6. code-on-demand

   서버가 클라이언트를 실행시킬 수 있는 로직을 전송하여 기능을 확장시킬 수 있다.(ex 자바스크립트)

 

이 중 잘 안지켜지는 것은 네번째 uniform interface이다.

이 uniform interface도 여러가지로 구성되어 있다.

1. identification of resources
2. manipulation of resources through representations
3. self-descriptive messages
4. hypermedia as the engine of application state(hateoas)

첫번째 identficaition of resources는 uri에 resource를 명시해야 함을 의미하고, 두번째 manipulation of resources through representations 는 리소스에 대한 조작 방법을 HTTP 메소드에 담으라는 것으로 이 두가지는 잘 지켜지는 반면에 세번째와 네번째는 잘 지켜지지 않는다.

 

• 4-3 메시지는 스스로 설명해야 한다.
  • conent-type 이나 host 등이 있어야됨
  • content-type: application/json-patch+json
  • → 이런식으로 op가 뭔지 나와야됨
• 4-4 어플리케이션의 상태는 Hyperlink를 이용해 전이되어야 한다
• 왜해야돼?
  • 서버와 클라이너트는 독립적으로 진화함으로
  • 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없다
• 지켜지고 있나?
  • ex) 웹 너무 잘지켜진다
    • 웹페이지를 변경해도 웹브라우저를 업데이트할 필요없다
    • 웹브라우저 업데이트해도 웹페이지 변경할 피요 없다
    • http, html명세가 바뀌어도 웹은 잘 동작한다
  • 계속 업데이트를 요구하는 어플? 웹이랑은 뭐가 달라서
  • 웹은 노력한다 w3c ietf
    • html5 초안에서 권고안에서 나오는데 6년
    • http/1.1 명세 개정판 작업하는데 7년
    • 상호운용성에 대한 집착
  • rest는 웹의 독립적 진화에 도움을 줌
  • 로이필딩이 http와 url 명세의 저자인것도 영향을 주는데 한목
• rest가 웹을 잘 도와준건 확인 그럼 rest api는?
  • 다 지켜야됨
• rest api는 오래 걸린다
• 그냥 http api를 사용할까? 그래도 사용해보자
• api는 웹페이지와 다르게 왜 힘들까
• media type이 웹은 html api는 json
  • html 하이퍼링크 있음 a태그
  • self-desscriptive html 명세
    • 모든 태그 다 정의되어 있음
  • json은 htperlink 정의되어있지 않고, self-descriptive 불완전
    • id나 title 뭔지 모르니까 self-descriptive x
    • 다음 상태로 전이될 링크가 없으니까 hatos x
• self-descriptive가 도움이 돼?
  • 서버나 클라가 변경되도 메시지는 언제나 해석 가능
• hateos
  • 링크는 동적으로 변경될 수 있다
• iana에 미디어 타입을 등록 id나 title이 뭔지 등등
  • 매번 media type을 등록해야됨
• 정보가 뭔지 http Link를 통해 profile relation으로 해당 명세를 링크
• hateos

 

 

- REST API 사용법

로이 필딩은 아니라고 하지만 우리가 보통 REST API는 어떻게 디자인할까?

데이터 resource를 URI로 표현한다. 이때 동사는 사용하지 않고 명사만 사용한다.

O https://junhee.com/foods

X https://junhee.com/getFoods 

 

정보의 가공방법 CRUD는 URI에 표시하지 않고 HTTP Headers안의 method를 이용한다.

HTTP 요청 메서드 - HTTP | MDN

Create: post

Read: get

Update: 전체 교체 put / 부분 patch

delete: delete

 

이를 이용해서 같은 URI여도 다른 목적을 가진 API를 만들 수 있다.

 

아래 메소드간의 차이가 나타나 있는 문서가 있다.

HTTP Methods GET vs POST

쿼리를 넣어 조건을 주기도 한다.