REST API
# API(Application Programming Interface)란?
프로그램들이 서로 소통하는 방법이다. interface라는 단어는 정형화된 버튼이라고 이해할 수 있다. 예를 들어, 우리는 컴퓨터를 사용할 때 글자를 입력하고 싶다면 키보드를 사용하고, 클릭을 하고 싶다면 마우스를 사용한다. 이때 키보드와 마우스가 interface이다. 우리는 interface를 통해 컴퓨터와 소통하고 있는 것이다. API 단어 속의 interface도 같은 의미이다. 프로그램들이 서로 데이터를 주고 받기 위해서는 소통 방법이 필요하다. 프로그램들이 서로 소통을 하기 위한 지정된 형식, 그것을 바로 API라고 한다.
# REST API
그렇다면 REST API란 무엇일까? API의 종류 중 하나로, 가장 널리 사용되는 API 방식이다. 우선 REST API의 등장 배경을 알아보기 위해 먼저 웹의 발전에 대해 짚고 넘어가자.
웹이 등장한 초기에는 사용자가 웹 페이지를 읽기만 하였다. 그러나 웹이 발달하면서 사용자는 웹 페이지의 내용을 읽을 뿐만 아니라 내용을 쓰고, 고치고, 지우는 역할(CRUD, Creat Read Update Delete)까지 하게 되었다. 사용자가 웹 페이지에 동작을 할 때마다 클라이언트와 서버는 서로 통신하는데, 웹이 발전함에 따라 클라이언트와 서버의 통신 횟수도 늘어나게 되었다. 이런 상황에서 클라이언트-서버 간의 일관된 통신 방식이 없다면? A컴퓨터와 통신할 때는 A방식, B컴퓨터와 통신할 때는 B방식, ... 을 사용한다면? 매우 불편할 것이다. 따라서 일관된 통신 방식이 필요해졌다. 이 일관된 통신 방식의 한 종류로 등장한 것이 바로 REST이다.
# REST(Representational State Transfer)란?
REST API란 말 그대로 REST한 방식을 사용하는 API이다. 그렇다면 REST란 무엇일까? REST란, 간단히 설명하자면 클라이언트 - 서버 간의 통신 방식 중 하나로, 1.자원을 이름으로 구분하여 2.자원의 상태를 주고 받는 통신 방식을 의미한다. 자원을 이름으로 구분하는 것, 자원의 상태를 주고 받는 것이 무슨 의미인지 알아보자.
1. 자원을 이름으로 구분한다.
REST에서는 자원을 URI로 표현한다. 책 데이터를 받고 싶다면 ~ /book, 사용자 데이터를 받고 싶다면 ~ /user와 같이 URI로 표현된 데이터를 요청한다. 이렇게 REST는 자원을 URI로 표현, 즉 URI로 구분한다.
API를 제작하는 개발자가 REST 방식으로 API를 제작하고 싶다면 URI의 이름을 직접 짓게 된다. 이때 URI의 이름은 규칙에 맞게 지어야 한다. (URI 네이밍 규칙) URI의 이름을 짓는 규칙에는 소문자를 사용할 것, 언더바 대신 하이픈을 사용할 것, URI 마지막에는 슬래시를 사용하지 말 것 등이 있다.
왜 규칙에 맞춰서 이름을 지어야 하는가? 일관된 규칙으로 이름을 지어야 개발자들이 헷갈리지 않기 때문이다. 예를 들어 책 API의 이름을 지을 때, 누구는 /book, 누구는 /getBookData, 누구는 /bookList, 이런 식으로 마음대로 이름을 지어버리면API를 사용하는 개발자들이 헷갈릴 것이다. API를 만드는 개발자와 API를 사용하는 개발자 간의 원활한 소통을 위해 규칙에 맞게 이름을 지어야 한다.
그리고 가장 중요한 것은, URI의 이름을 지을 때 API 데이터를 어떻게 사용하는지에 해당하는 단어는 넣지 않아야 한다. 이게 무슨 뜻이냐면, 우리는 API로 데이터를 가져오거나 수정한다. 그리고 이 데이터를 어떻게 사용할지는 HTTP로 결정한다. /book 이라는 API가 있다면 이 API의 데이터를 가져올지, 수정할지, 삭제할지는 HTTP로 결정한다. 그러니 /get-book
처럼 API의 이름 자체에 동작에 대한 단어를 포함하면 안 된다.
2. 자원의 상태를 주고 받는다.
앞에서는 자원, 즉 API의 데이터의 이름에 대해 알아보았다. 그렇다면 그 데이터를 어떻게 사용하면 될까? 위에서 언급했듯 HTTP를 이용한다. API 데이터에 이름을 붙였고, 그 이름을 HTTP를 이용하여 사용하게 되는 것이다.
HTTP에는 다양한 메소드(≓ 내장 함수)가 있다. HTTP의 GET을 이용하면 데이터를 받아와서 읽을 수 있고, POST를 이용하면 새로운 데이터를 생성/업데이트할 수 있다. 이외에도 PUT, DELETE 등 다양한 종류의 메소드가 있다.
HTTP 메소드의 종류 : https://developer.mozilla.org/ko/docs/Web/HTTP/Methods
이렇게 클라이언트 쪽에서 GET, POST, PUT 등의 방식으로 데이터를 요청하면, 요청을 받은 서버는 요청에 대해 응답한다. 이때 서버는 상태 코드를 사용하여 응답 상태를 알려준다. 상태 코드는 100부터 500까지의 숫자로 표현된다. 웹 사이트를 사용하다가 404 Not Found라는 페이지를 본 적 있는가? 그 404가 바로 상태 코드 중 한 종류이다.
| 1XX | 조건부 응답 |
| 2XX | 응답 성공 |
| 3XX | 리다이렉션 완료 |
| 4XX | 요청 오류 |
| 5XX | 서버 오류 |
상태 코드의 종류 : https://developer.mozilla.org/ko/docs/Web/HTTP/Status
API 요청이 성공했다면 200 ok 라는 응답을 볼 수 있다. 혹은 요청에 오류가 있거나 서버의 상태가 좋지 않다면 4xx, 5xx의 상태 코드가 응답된다. 이렇게 상태 코드를 이용하면 API 요청이 제대로 되었는지 확인할 수 있다.
REST는 자원을 이름으로 구분하여 자원의 상태를 주고 받는 통신 방식이다. 그리고 REST API는 REST 방식을 이용한 클라이언트 - 서버 간의 통신 방식이다. 이를 종합하여 설명하자면, /users라는 이름의 API가 있다고 하자. 이 API를 사용하고 싶다면 HTTP의 GET 메소드를 이용하여 데이터를 읽고 싶다는 요청을 보내거나 POST 메소드를 이용하여 수정, 업데이트하고 싶다는 요청을 보낼 수 있다. 그럼 이 요청을 받은 서버는 상태 코드로 응답해준다. 200이라는 상태 코드가 응답되었다면 API를 정상적으로 사용할 수 있다는 것이고, 그렇지 않다면 무언가 문제가 있다는 것이니 상태 코드의 번호를 확인해보면 된다.
REST라는 개념을 조금 더 자세히 살펴보자면, REST는 6가지 조건을 만족한다. 그 6가지 조건에 대해 알아보자.
# REST의 6가지 조건
1. client-server : 클라이언트의 요청과 서버의 응답으로 통신한다.
2. stateless : 이전 상황, 즉 문맥이 없어도 통신할 수 있다.
3. cache : 서버의 응답 메시지는 캐싱(저장 후 재사용)될 수 있다.
4. uniform interface : URI와 HTTP 같은 지정된 인터페이스를 준수한다.
5. layered system : 기능이 계층별로 나누어져 있다. 그래서 중간 계층의 기능이 변경되어도 통신에 영향이 없다.
6. code-on-demand (optional) : 데이터 처리를 쉽게 하기 위해 서버가 클라이언트에게 스크립트를 전송할 수 있다.
API가 뭔지도 모르고 그냥 썼었는데 이제 좀 알 것 같다. 근데 REST의 조건은 그냥 HTTP의 조건과 크게 다른 점을 잘 모르겠는데...🤔 REST가 HTTP를 이용하는 방식이기 때문에 HTTP의 내용과 좀 겹치는 걸까 갑자기 궁금해짐
참고 자료
https://developer.mozilla.org/ko/docs/Web/HTTP/Methods
https://developer.mozilla.org/ko/docs/Web/HTTP/Status
'CS > WEB & 네트워크' 카테고리의 다른 글
| [네트워크] Cross Origin Resource Sharing (CORS) (0) | 2023.02.10 |
|---|---|
| [네트워크] HTTP (0) | 2023.01.08 |
| [WEB] SPA, MPA와 CSR, SSR, SSG (0) | 2022.11.29 |
| [WEB] 브라우저 렌더링과 DOM (0) | 2022.11.09 |
| [WEB] 브라우저 저장소 (0) | 2022.11.06 |
