본격적인 1차 프로젝트 중인 현 시점, 자신이 백엔드와 프론트의 경계에 걸쳐져 있는 이러한 부분들에 대해 얼마나 무지한지에 대해 피부로 느끼게 되었다. 백엔드에서 정성스레 만들어준 데이터를 프론트에서 잘 받으려면 기본적인 지식부터 짚고 넘어가야겠다는 생각에 정리해보는 이번 포스트.
API에 대한 무지는 2인 자전거의 이음새 부분을 끊는 행위나 다름없다.
그런 의미에서 API, CRUD, RESTful API에 대해 정리해보는 시간을 가져보자.
API
서버는 사용자의 요청에 따라 적합한 처리를 해서 응답을 준다. 이때 어떤 요청이 "회원 가입 시켜줘", "상품 리스트 페이지 연결해줘"라는 요청인지 알 수 있게 하는 체계가 바로 API 이다. 다시 말해 API란, 클라이언트, 서버와 같은 서로 다른 프로그램에서 요청과 응답을 주고 받을 수 있게 만든 체계이다.
이때 응답을 주는 쪽에서 사전에 "여기로 요청을 보내면 이러한 응답을 주고, 저기로 요청을 보내면 저러한 응답을 줄께'라는 정의가 필요하다. 그래야 요청하는 쪽에서 정확한 곳에 요청을 보낼 수 있다. 여기서 의미하는 '정확한 곳'이란 '서버주소/A'형태로 정의되어 있다. 여기서 '서버 주소'란 컴퓨터가 위치한 곳의 IP 주소(ex. 192.168.123.132) 이다.
예를 들어, '서버주소/A'라고 신호를 보내면 서버가 '회원 가입 기능'을 수행하고 응답한다. 혹은 '서버주소/B'라고 신호를 보내면 서버가 '상품 리스트 페이지'를 수행하고 응답한다.
이러한 API를 만들 때는 데이터를 주고 받는 기능도 함께 넣는다.
대표적인 예로, 네이버에서 로그인 요청을 할 때 아이디와 비밀번호 데이터가 필요하다.
이때 API를 통해 요청과 응답을 주고 받으며 데이터도 같이 담긴다.
이러한 기능은 서버 개발자가 만들며, 그 결과물이 바로 서버 프로그램이다. 즉, API를 백엔드에서 개발하면 프런트에서는 그 API를 사용하면 된다.
이제 API를 클라이언트와 서버의 관점에서 좀 더 자세히 살펴보자.
CRUD
인스타그램에 사진을 올릴 때의 경험을 떠올려보자.
우리가 사진을 업로드하고 <게시> 버튼을 누르는 과정 속에 클라이언트 소프트웨어는 서버에 '피드에 사진을 올리는' 요청을 보낸다. 우리는 피드에 사진을 올리거나, 외부에서 불러오거나, 사진을 수정하거나, 아예 지워버리는 요청을 할 수 있다.
은근슬쩍 과외 강아지 자랑하고 싶은거 맞다
우리가 서버로부터 원하는 이 4가지 요청을 크게 4가지 요소로 나누어 CRUD라고 부른다.
CRUD란, 데이터를 다룰 때 기준이 되는 4가지 요청이다.
C (Create)
R (Read)
U (Update)
D (Delete)
C는 Create의 약자로 피드에 사진을 '올리는' 요청을 의미한다.
R은 Read의 약자로 피드에 사진을 '불러오는' 요청을 뜻한다.
U는 Update의 약자로 피드의 사진을 다른 사진으로 '바꾸는' 요청을 의미한다.
D는 Delete의 약자로 피드의 사진을 '지우는' 요청을 뜻한다.
Restful API
타임라인의 CRUD요청은 각각의 주소를 가지며 서버의 기능을 원하는 클라이언트는 해당 주소로 요청을 보내면 된다. 하지만 이런식으로 주소를 구성하면 주소의 양이 방대해질 뿐더러 관리하기도 힘들어진다.
따라서 사람들은 좀 더 체계적으로 API를 관리하고 싶어 했고 그 영향으로 체계적인 API, 즉 RESTful API 가 탄생했다. RESTful API의 REST는 Representational State Transfer의 약자이다.
RESTful API에서는 이전보다 주소의 양이 현저히 줄어들며 CRUD를 단 하나의 주소로 관리한다. 그리고 요청을 보낼 때 다음과 같이 어떤 요청을 보냈는지 파악할 수 있는 메서드를 함께 붙여서 전송한다.
- Create (생성) : POST
- Read (받아오기) : GET
- Update (수정) : PUT(전체) / PATCH(일부)
- Delete (삭제) : DELETE
//method 예시
fetch('https://jsonplaceholder.typicode.com/posts', {
method: 'POST',
});
이때 클라이언트에서 요청을 보내면, 서버는 두가지 응답을 보내줄 수 있다. 하나는 "잘 됐어!"와 다른 하나는 "실패했어.."가 되겠다. 통신에 성공한 "잘됐어!"의 경우 statuscode는 200번대의 코드를 표현하며 ok 값이 true이다. 통신에 실패한 "실패했어.."의 경우에는 statuscode가 400번대(클라이언트 오류) 혹은 500번대(서버 오류)일 때 ok가 false로 반환이 된다.
--> 위 해석은 microsoft 2016을 기반으로 작성하였으며 창시자인 Roy Fielding의 해석과는 다소 차이가 있습니다.
JSON
JSON은 JavaScript Object Notation으로 속성 값, 배열 자료형 "키 key - 값 value"로 이루어진 데이터 객체로 이러한 데이터를 주고 받을 때 사용하는 형식 중에 가장 많이 사용한다.
//JSON 기본 형식
{
키1(Key) : 값1(Value),
키2(Key) : 값2(Value),
}// 상품 정보 예시
{
"category" : "고기",
"sort" : "돼지",
"items" : ["삼겹살", "목살", "항정살"],
}이런 식으로 객체 안에 배열을 넣는 형식을 취하면 여러 상품을 한번에 불러올 수 있다.
JSON의 장점으로는
- 기계와 사람 모두 인식하고 읽기 쉬운 텍스트 형태로 이루어져 있다.
- 프로그래밍 언어와 플랫폼에 독립적이므로, 서로 다른 시스템 간에 객체를 교환할 수 있다 (Ex. 파이썬 <-> 자바스크립트)
기본 용어들을 정리하니 API 통신에 관한 기본 문서들의 의미를 이해하는데에 더 많은 도움이 되었다. 이제 실제 프로젝트에 적절하게 적용할 수 있도록 직접 JSON파일과 Fetch함수를 이용하여 데이터를 받아오는 연습을 할 예정이다.
