API
API는 application programming Interface의 줄임말로, 애플리케이션만을 말하는 게 아닌 함수도 API에 해당된다. server 입장에서의 API는 client가 사용할 수 있는 URL과 같은 것을 의미한다.
API를 RESTful하게 만든다는 것은 'REST의 성격을 지닌 API를 만들겠다'는 것이다.
REST
그렇다면 REST란 무엇인가? REST는 Representational State Transfer의 줄임말로, 대표하는 상태 전송이라고 해석된다. 즉, 무엇인가를 나타내거나 대표할 수 있는 상태를 전송하는 것을 의미한다. 쉽게 생각하자면 서비스를 만들 때 우리가 지켜야할, 지키면 좋은 가이드라인과 비슷하다고 생각하면 좋을 것 같다.
자세히 알아보기 👓
server에는 다양한 데이터들이 존재한다. 이러한 데이터들을 그룹화하여 관련된 것들을 URL 형태로 client에게 제공한다. client는 server에서 제공하는 URL들 중 하나를 골라 요청할 수 있고, server는 요청한 것에 해당하는 것에 대한 데이터를 client에게 보내준다.
🤔 좀 더 심플하게, REST를 말하자면?
: HTTP method를 이용해 URL을 디자인 하는, API를 디자인하는 것이다.
RESTful System
server와 client간의 HTTP를 이용한 통신이 많아지고, 이를 좀 더 효율적으로 설계하기위해 나타난 것이 RESTful System이다. RESTful System을 만들기 위해서는 아래의 6가지 지침을 지켜야한다.
RESTful System 제작을 위한 6가지 조건들
1. client와 server의 Architecture
서버는 client가 브라우저든, 모바일이든 다양한 어플리케이션에 데이터를 제공할 수 있는 아키텍처를 제공해야 한다.
2. statelessness
하나의 요청이 다른 요청과 연관(연결)되지 않는 'stateless'한 상태로 서버를 디자인 해야한다.
3. Cacheability
캐시가 가능하다면, 캐시를 할 수 있는 것으로 디자인 해야한다. 사실 위의 statelessness와 Cacheability는 HTTP 프로토콜을 통해 자동으로 충족할 수 있는 조건들이다.
4. layered System
뒤에 얼마나 많은 서버가 있냐에 상관없이 하나의 API를 사용할 수 있도록 'Layered System'을 사용해야한다.
5. Code on demand
client가 원한다면 client에서 수행해야하는 코드를 서버에서 client로 보내줄 수 있다. 이는 옵션이다.
6. Uniform interface
이것이 바로 RESTful한 system인지 아닌지를 결정하는 중요한 요소이다. 이는 아래에서 자세히 알아보자.
📌 간단히 정리하자면
: client 종류에 관계없이 데이터를 제공할 수 있어야하고, 하나의 공통된 API를 이용해 client가 서버에 어떻게 구조되어있는지에 관계없이 API를 이용할 수 있어야 한다.
6번째 조건, Uniform Interface에 대하여
Uniform Interface에는 4가지 특징이 있다.
1. Resource Identification in requests
client 요청에서, 서버에 있는 어떤 리소스나 도메인데이터를 원하는지 식별 가능해야 한다. 또한 서버에 저장된 데이터들이 어떻게 저장되어 있는가에 상관없이 client에 있는 형식(format)대로(즉, client가 요청한대로) 데이터를 보내주어야 한다.
2. Resource manipulation through representations
서버로부터 받은 해당 도메인을 대표할 수 있는 데이터를 통해, 해당 리소스에 대해서 앞으로 수정이나 삭제를 할 때 어떻게 요청할 수 있는지에 대한 모든 정보를 알 수 있어야한다.
3. Self-descriptive messages
서버에서 보내는 응답 데이터 안에는 반드시 client가 이 데이터를 어떻게 처리해야하는지 설명되어져 있어야 한다. (마치 HTTP 헤더에 Content-type을 지정해주는 것처럼 말이다.)
4. HATEOAS; Hypermedia as the engine of application state
하이퍼미디어를 어플리케이션 엔진처럼 제공해야한다. 서버에 URL이 있다면 client가 서버에 어떤 URL이 있는지 알아야하고, 적절한 URL로 요청해야 한다. client 측에서 신경써서 서버에 URL을 요청해야 한다.
API를 디자인하는 방법: CRUD
서버에 있는 특정한 데이터를 client가 새로 만들거나(Create), 읽거나(Read), 수정하거나(Update), 삭제(Delete)할 수 있게끔 API를 디자인하는 것이 일반적이다.
CRUD를 HTTP와 비교해서 설명해보자면, 아래의 표처럼 나타낼 수 있다.
| CRUD | HTTP |
|---|---|
| Create | POST |
| Read | GET |
| Update | PUT |
| Delete | DELETE |
🤔 TIP!?
REST한 API를 만들 때 Action과 What이 드러나게끔 표현하면 된다.
- 'What': 서버에 있는 어떤 데이터를
- 'Action': 어떻게 할 것인가? (ex. POST, GET, PUT, DELETE)
예를 들어 GET /posts/getPosts 처럼 나타내진 것은 /posts로 바꿀 수 있다.
이미 HTTP 메소드로 어떻게 할 것인지를 알 수 있으니, URL에는 어떤 데이터에 대한 것인지만 나타내면 되는 것이다. 이런식으로 생각해보았을 때, 다음과 같이 짜볼 수 있다.
- 포스트 생성하기
POST/posts
- 포스트 안에 id가 1인 포스트 가져오기
GET/posts/1
- id가 1인 포스트 업데이트 하기
PUT/posts/1
- id가 1인 포스트 삭제하기
DELETE/posts/1
