REST API

woolee의 기록보관소·2022년 10월 31일

목록 보기

19/35

API

Application Programming Interface의 약자로, 서로 다른 프로그램 간 소통할 수 있게 도와주는 통신 규약. API는 프로그램과 프로그램 간 매개체 역할을 한다.

이걸 웹에 적용하자면 서버와 클라이언트 간 통신 규약을 말한다. 클라이언트 관점에서 보자면, 서버에 요청해서 데이터를 가져오는 방법을 말한다. 클라이언트는 서버와 직접적으로 통신하는 게 아니라 API 서버와 통신한다.

앱 또는 웹 상에서 동작하는 어플리케이션을 개발할 때 주로 HTTP 또는 HTTPS를 사용해 API를 정의한다.

API 정의 과정에서 우리가 사용할 수 있는 요소는 HTTP와 URI이다.

GET https://restapi.example.com/home/apartment/...

여기서 URI와 URL의 차이점을 알아야 하는데, URI는 자료를 넘버링하고 분류하고 지칭하는 방법이다. URL보다 큰 개념이다.

URL은 Uniform Resource Locator의 약자. 인터넷 상 자원 위치 표기를 위한 규약이다. WWW의 주요 요소인 HTML, URL, HTTP 중 하나이다.

URI는 뒤에 Identifier가 들어간다. URL이 자원의 위치를 나타내는 것이라면 URI는 유니크한 리소스를 가리킨다.

예를 들어,

https://restapi.example.com/home.html

⇒ 웹서버의 실제 파일 위치를 나타내는 주소이므로 URL이자 URI이다.

https://restapi.example.com/home.html?id=wejaan&pw=1225

⇒ ?식별자와 함께 파라미터가 뒤에 붙는데, 앞부분인 https://restapi.example.com/home.html가 URL이라면, URI는 뒤에 있는 파라미터까지 포함한다. 뒤에 있는 파라미터까지 전부 포함해야 유니크한 리소스이므로.

REST

REST는 REpresentational State Transfer의 약자로, 자원의 이름(자원의 표현)으로 구분해 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미한다.

서버가 가지고 있는 리소스의 상태를 표현해서 전달하는 것. REST는 결국 리소스를 어떻게 하면 명확하게 표현할 수 있는지에 집중하는 아키텍처 스타일이다(REST는 protocol이나 standard가 아니라 a set of architectural constraints이다).

로이 필딩(Roy Fielding)이 주장한 API 디자인 방법.
웹의 장점을 최대한 활용하자.⇒ "웹 API 짤 때, REST 원칙을 지키면 좋다."

초기에 웹(HTTP)를 제대로 사용하지 못하는 걸 보며 웹의 장점을 최대한 활용할 수 있는 아키텍처(소프트웨어 프로그램 아키텍처)로서의 REST가 탄생되었다고 한다. 그러므로 웹의 기존 기술과 HTTP 프로토콜을 활용해서, 웹의 장점을 최대한 활용할 수 있는 아키텍처인 것이다. 즉, REST는 네트워크 상에서 client와 server의 통신 방식 중 하나이다.
⇒ 성능의 향상보다는 규칙을 통해 API 이해도와 호환성을 높이는 게 목적. (유지 보수 및 코드의 재사용성을 높이는)

REST의 구성요소

REST는 자원(resource)의 표현(representation)에 의한 상태 전달. HTTP URI를 통해 자원을 표현하고, HTTP Method를 통해 자원에 대한 CRUD Operation을 적용한다.
⇒ Create 생성 (POST), Read 조회 (GET), Update 수정 (PUT), Delete 삭제 (Delete)

자원(Resource) ⇒ URI

모든 자원에는 자원을 구별하는 고유한 ID(HTTP URI)가 존재하고, 이 자원은 서버에 존재한다.

클라이언트는 URI를 이용해 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 서버에 요청한다.

행위(Verb) ⇒ HTTP Method

HTTP의 GET, POST, PUT, PATCH, DELETE의 Method를 사용한다.

⇒ (CRUD)

GET : Read(정보 요청, URI가 가진 정보를 검색하기 위해 서버에 요청)
POST : Create(정보 입력, 클라이언트에서 서버로 전달하려는 정보를 보냄)
PUT : Updata(정보 업데이트, 데이터 전체 변경(갱신))
PATCH : Updata(정보 업데이트, 데이터 일부 변경(갱신))
DELETE : Delete(정보 삭제, 안전성 문제로 대부분 비활성화)

표현(Representation of Resource)

클라이언트client가 서버server와 데이터를 주고 받는 형태로, JSON, XML, TEXT, RSS 등이 있다. (JSON, XML로 하는 게 일반적)

어떤 자원에 대해 CRUD(Create, Read, Update, Delete) 연산을 수행하기 위해 URI(Resource)로, GET, POST 등의 방식(Method)을 사용해 요청을 보내며, 요청을 위한 자원은 특정한 형태(Representation of Resource)로 표현된다고 한다.

즉, URI는 정보의 자원을 표현해야 하며
자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.

REST는 리소스가 어떻게 표현되는지에 집중하고 
URI를 통해 어떤 리소스인지 알아내고 
HTTP 메서드를 통해 어떤 행위인지 알아낸다.

REST 특징 (로이 필딩이 주장한 REST 원칙 6가지)

서버 클라이언트 구조

자원을 가진 쪽이 서버, 자원을 요청하는 쪽이 클라이언트가 된다. REST 서버는 API를 제공하고 비즈니스 로직 처리 및 저장을 책임지고, 클라이언트는 사용자 인증이나 context(세션, 로그인 정보) 등을 직접 관리하고 책임진다.

클라이언트 역할과 서버 역할을 구분하고, 서로 역할을 바꾸거나 하지 않는다.

Stateless (무상태성)

HTTP는 stateless protocol이므로 REST 역시 무상태성을 갖는다.

클라이언트의 context를 서버에 저장하지 않는다.
(세션과 쿠키 같은 context 정보를 신경쓰지 않으므로 구현이 단순해진다)
서버는 각각의 요청을 완전히 별개의 것으로 인식한다. (각 API 서버는 클라이언트의 요청만을 단순히 처리, 이전 요청이 다음 요청의 처리에 연관되지 않도록, DB에 의해 바뀌는 건 허용)
요청들이 각각 독립적으로 처리되어야 한다. 요청 간 의존성이 있는 코드를 짜지 말라는 것이다. 다르게 말하면, 요청 하나만으로 필요한 모든 정보를 실어 보내는 게 좋다는 의미이기도 하다.

Casheable (캐시 처리)

웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존 인프라를 그대로 활용. 즉, HTTP가 가진 강력한 기능인 캐시 기능을 사용할 수 있고, 대량의 요청을 효율적으로 처리할 수 있다.

요청을 통해 보내는 자료들은 캐싱이 가능해야 한다. 그리고 캐싱이 가능하다고 표시하거나 캐싱 기간을 설정해줘야 한다.
캐싱이란?
특정 웹사이트를 방문하면, 브라우저는 자주 사용하는 이미지 파일, CSS 파일 등을 하드에 저장해놓는다. 다음에 또 방문할 때, 서버에 요청하지 않아도 하드웨어에서 불러오는 것. 이 행위를 캐싱이라고 한다.

Layered System (계층 구조)

클라이언트는 REST API 서버만 호출한다. REST 서버는 다중 계층으로 구성될 수 있다. 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 프록시PROXY, 게이트웨이 같은 네트워크 기반의 중간매체 사용할 수 있다.

Uniform Interface

URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 의미.

즉, 인터페이스가 일관성이 있어야 한다. 하나의 URL로는 하나의 데이터를 가져와야 하고, 간결하고 예측 가능하게 코드를 짜야 하고, URL 이름 짓는 관습을 따라야 한다.

Self-Descriptiveness

REST API 메시지만 봐도 쉽게 이해할 수 있는 자체 표현 구조를 가진다는 의미.

페이스북의 URL 예시

instagram.com/explore/tags/kpopinstagram.com/explore/tags/foodfacebook.com/natgeo/photosfacebook.com/bbc/photos

단어들을 동사보다는 명사 위주로 구성하기
응용해서 다른 정보들을 쉽게 가져올 수 있을 정도로 일관성 있게
대충봐도 어떤 정보가 들어올지 예측하기 쉽도록
띄어쓰기는 언더바_ 대신 대시-기호 사용하기
파일 확장자 쓰지 말기 (.html 같은)
하위 문서들을 뜻할 때는 /(슬래쉬) 기호를 사용하기 (하위폴더 의미)
마지막 문자로 /(슬래쉬) 사용하지 않기
URI 경로에는 소문자가 적합함
...

Rest(ful) API

HTTP는 인터넷에서 데이터를 가져와 사용하기 위해 만들어진 프로토콜이고 초기에는 html 파일을 가져오기 위해서 설계를 했지만, 사실 html만 가져올 수 있는 게 아니었다. 마치 함수를 사용하듯이 파라미터를 넣고 원하는 값을 반환하듯이 쓸 수 있으므로, html 이외에 인터넷 상에서의 데이터를 가져오기 위한 용도로 쓰기 때문의 REST API라는 이름이 붙었다. 그래서 리소스(URI)를 지정해주면 그 리소스(주소)에 맞게 결과를 가져올 수 있다.

오늘날 웹페이지의 규모가 커지면서 하나의 서버로 모든 기능을 감당하기 어려우므로 각각의 데이터를 담당하는 서버에 rest api를 사용해서 결과를 모아 html 페이지를 구성한다.

REST API는 REST의 규칙을 지켜서 만든 API이며, Restful API란, REST의 규칙을 잘 지켜서 설계된 API를 말한다.

rest api가 많이 사용되는데, 규칙을 잘 지킨 api를 설계하려는 목적에서 restful api 개념이 등장한 것이다.
위와 같이 restful하다는 건,
http 메서드를 적합하게 사용하고(기능에 적합한 URL 메서드 사용), path도 이렇게 규칙에 맞게 만드는 걸 말한다.