개발 공부를 하면서 자주 들은 것은 RESTful한 API가 중요하다는 것이었다.
API의 개념은 어느정도 알겠지만, 그 중에서도 RESTful한 API는 뭔지, 그리고 그게 왜 중요한지에 대해선 항상 대강 짚고만 넘어갔었다.
자주 들어본 개념인만큼 한번쯤은 꼭 정리해야겠다고 생각해서 이번에 한번 검색을 살짝 해봤다.
1. "API" 와 "RESTful API" 는 뭐가 다른걸까?
✅ API를 정의해보자! (feat. AWS)
API는 Application Programming Interface(애플리케이션 프로그램 인터페이스)의 줄임말로서, 요청과 응답을 사용해서 두 어플리케이션이 서로 통신하는 방법을 정의한다고 한다.
API는 개발자간의 상호협의이자, 요청과 응답을 구성하는 방법에 대한 정보가 들어있다고 한다.
클라이언트 (프론트)가 요청을 보내면, 해당 요청이 갖고있는 정보를 토대로 응답 데이터를 서버 (백엔드)가 전달한다. REST API는 그 중 가장 많이 사용되고 유연한 API의 한 종류라고한다.
클라이언트가 서버에 요청을 데이터로 전송하면, 서버가 이 클라이언트 입력을 사용하여 내부 함수를 시작하고 응답 데이터를 다시 클라이언트에 반환하는 과정이다.
API라고해서 꼭 백엔드, 프론트엔드의 소통만을 의미하는 것은 아니고, 굳이 따지면 응용 프로그램에서 사용할수 있도록, 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만드는 인터페이스를 뜻하는 말이라고 한다.
그렇기 때문에 API도 종류가 많은데, 요즘 소통을 위해 자주 쓰이는 것이 REST API인 것이다.
2. 그래서 REST API가 무슨 뜻인데?
REST API에서 REST의 약자는 Representational State Transfer라고 한다.
여기서 말 하는 REST를 정리하자면, "표현할 수 있는 어떠한 방식으로 상태를 전송한다" 라는 의미를 갖고 있다고 볼 수 있겠다.
❗️ 쉽게 말해서 HTTP를 잘사용하기 위한 아키텍쳐 스타일이라는 것!
✅ REST API의 구성
-
REST API는 아래와 같은 구성으로 이뤄져있다.
구성 요소 내용 표현 방법 Resource 자원 HTTP URI Verb 자원에 대한 행위 HTTP Method Representations 자원에 대한 행위의 내용 HTTP Message Pay Load
-
CRUD 구현 시, 각각 기능에 맞는 http method를 사용해서 소통이 진행되어야 한다.
Method Action 역할 페이로드 GET index/retrieve 모든/특정 리소스를 조회 x POST create 리소스를 생성 ○ PUT replace 리소스의 전체를 교체 ○ PATCH modify 리소스의 일부를 수정 ○ DELETE delete 모든/특정 리소스를 삭제 x -
페이로드가 있는 경우, 클라이언트 쪽에서 해당하는 페이로드를 보내야 서버에선 그 페이로드로 작업을 할 수 있다.
-
페이로드가 없는 경우는 페이로드를 직접 보내진 않지만, uri에 서버에서 응답받을 때 특정할 수 있는 값을 넣어서 요청을 보내야한다. ex. 특정 게시물의 id값
이런 REST 형식으로 API를 구성하면, 그때서야 그 API는 RESTful API가 되는 것이다. 그리고 REST API는 몇 가지 원칙을 지켜야한다고 한다.
-
URI는 정보의 자원을 표현해야 한다.
-
모든 자원엔 고유한 ID가 존재하고, 이 자원은 서버에 존재한다. 자원을 구분하는 ID값을 포함한 주소가 HTTP URI라고 한다.
-
client는 uri를 이용해서 서버에 정보를 요청할 때 특정 자원에 대한 정보를 요청하거나 변경된 내용을 전달할 수 있는 것이다.
-
리소스명은 동사보다는 명사를 사용한다. URI는 자원을 표현하는데 중점을 두어야 한다. get 같은 행위에 대한 표현이 들어가서는 안된다.
# bad GET /getTodos/1 // 명사가 아닌 동사로 리소스를 표현 GET /todos/show/1 // get의 대한 표현인 show가 들어감 # good GET /todos/1 // get (http method)으로 자원에 대한 행위를 표현했고, 명사로 자원을 표현했다.
-
-
자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)으로 표현한다.
-
URI에 따로 명시할 필요 없이 HTTP Method만으로 행위를 표현해야한다.
-
REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태로 표현될 수 있다.
-
보통 JSON 혹은 XML 형식으로 데이터를 주고 받는다.
# bad GET /todos/delete/1 // 자원에 대한 행위가 http method가 아닌 uri에 표현되었다. # good DELETE /todos/1 // http method를 이용해서 행위가 표현되었다.
-
-
계층 구조는 슬래시로 구분해서 표현한다.
-
uri의 마지막 부분에는 슬래시를 사용하지 않는다.
# bad GET /postList-todos-1 // 계층 관계는 슬래시를 사용한다. # good GET /postList/todos/1 // 1번 todo가 위치한 곳은 postList 중, todos 중 1번이다.
-
-
가독성을 높여하는 경우, 밑줄(_) 보단 하이픈(-)을 사용한다.
-
밑줄은 보기 어렵거나 밑줄 때문에 문자가 가려지기 때문에 하이픈(-)을 사용한다.
# bad GET /postList_todos_1 // 밑줄은 사용하지 않는다. # good GET /postList/my-todos/1 // 가독성을 위한 띄어쓰기는 하이픈으로 대체한다.
-
-
메시지 바디 내용의 포맷은 URI에 표현하지 않고 accept 헤더를 사용한다.
-
content-type:
-
요청과 응답 모두!! 보낼 데이터의 형식을 알려주는 헤더
-
만약 따로 정의하지 않고 요청 혹은 응답을 보냈다면, 데이터를 전송하는 쪽(클라이언트와 서버)에서 해당 데이터가 특정한 형식의 데이터일지라도 데이터를 받는 입장에서는 단순히 text로 받아들인다.
-
GET 요청 시 무조건 text 형식으로 보내지기 때문에 content-type을 지정해줄 필요 없다.
-
POST, PUT 요청 할 때 body에 데이터를 담아 보내게 된다면, content-type을 지정해줄 필요가 있다.
- ex)
{"content-type": "application/json"}
- ex)
-
-
accept header:
-
클라이언트에서 서버로 요청시 요청메세지에 담기는 헤더
-
클라이언트가 서버에게 "나는 이러한 데이터 타입만 받겠소" 하는 것과 같다.
-
만약
{accept: "application/json}을 보냈다면 서버는 json 형식으로 응답을 해줘야한다.
-
-
둘 다 데이터 타입(MIME)을 다루는 헤더이다. 하지만 Content-Type 헤더는 현재 전송하는 데이터가 어떤 타입인지에 대한 설명을 하는 개념이고 Accept 헤더는 클라이언트가 서버에게 어떤 특정한 데이터 타입을 보낼때 클라이언트가 보낸 특정 데이터 타입으로만 응답을 해야한다.
-
✅ REST API 특징
1. Uniform Interface (유니폼 인터페이스)
- URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다.
2. Stateless (무상태성)
- 작업을 위한 상태정보를 따로 저장하고 관리하지 않는다.
- 세션 정보나 쿠키정보를 별도로 저장하고 관리하지 않기 때문에 API 서버는 들어오는 요청만을 단순히 처리한다.
- 클라이언트가 보내는 요청이 매번 개별 요청으로 인식이되기 때문에 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순해진다.
3. Cacheable (캐시 가능)
- REST의 가장 큰 특징 중 하나는 HTTP라는 기존 웹표준을 그대로 사용하기 때문에, HTTP가 가진 캐싱 기능을 적용할 수 있다.
- HTTP 프로토콜 표준에서 사용하는 Last-Modified태그나 E-Tag를 이용한 캐싱 구현이 가능하다.
4. Self-descriptiveness (자체 표현 구조)
- 클라이언트 쪽에서 REST API 메시지만 보고도 이를 쉽게 이해 하고, 정보를 어떻게 활용할 수 있는지 알 수 있는 자체 표현 구조로 되어 있어야한다.
5. Client - Server 구조
- REST 서버는 API를 제공하고, 클라이언트는 사용자 인증이나 context(세션, 로그인 정보)등을 직접 관리하는 구조로 각각의 역할이 확실히 구분된다.
- 분리되어있기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로간 의존성이 줄어든다.
6. 계층형 구조
- 클라이언트는 REST API 서버만 호출한다.
- REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있다.
- PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있다.
그 동안 프로젝트를 진행하면서 API 명세서를 계속 봐았지만, API가 왜 특정 형식으로 구성이 되었는지 알게 되었다.
지금까지는 흘러들어서 대강만 파악하고 있던 얘기가 조금 더 머릿속에 명확하게 자리 잡았다.
앞으로도 가끔 명확하지 않게 알고있던 내용에 대해 블로그 글을 남겨두는 것이 큰 도움이 될 것 같다.
출처:
