API 통신

API 통신과 백엔드 작업에 대하여


들어가며

작년 그룹원들에게 지식공유차 백엔드 작업에 대하여 라는 주제로 백엔드 시스템의 간단한 설명과 예시를 안내한 적이 있다.
이번시간에는 그때의 기억을 되살리는(혹은 다음 지식공유를 위한) 시간을 갖고자 한다.

백엔드란??

우리가 SPA데이터 바인드 작업을 하게 되면 마주하게 되는 API통신을 다들 잘 알 것이라고 생각한다.
백엔드는 바로 이 API데이터를 전달해주는 것으로 데이터베이스와 컴퓨터 사이 인터페이스 영역을 말한다.
프론트엔드에서 약속된 규칙대로 서버에 요청을 보내면 서버에서는 요청받은 규칙을 토대로 요청자가 원하는 데이터를 가공하여 값을 혹은 상태를 전달해 준다.

데이터베이스

데이터베이스는 데이터 저장소이다.
예를 하나 들어보자면 A라는 웹 사이트에 회원가입을 하고 로그인 후 게시판에 글을 작성할 경우, 사용자정보, 게시판 작성 글 정보는 어디서 가져오는 것 일까?
바로 이 정보들을 담고 있는 것이 저장소 이다.
사용자정보, 게시판정보, 댓글정보 등등… 많은 자료들을 보관하고 관리할 수 있는 것으로 각각의 정보집합군을 테이블 이라고 한다.
이를테면 사용자정보 테이블에는 아이디, 이름, 비밀번호, 연락처, 가입일 등의 정보를 담을 수 있는 구조로 되어 있는 것 이다.
이 테이블 들은 기본적으로 CRUD라고 하여 Create(등록), Read(조회), Update(수정), Delete(삭제) 라는 명령 쿼리를 통해 데이터 작업이 일어나게 된다.

API

API는 프론트엔드 프로젝트에서 데이터 바인딩을 위해 서버에 호출요청을 하는 정보 이다.
대개 백엔드 개발팀에서 데이터베이스에 접근 하고 정보를 조회 및 가공 후 화면으로 넘겨주는 하나의 작업이다.
형태나 사용 용도에 따라 GET, Patch(Put), POST, DELETE 등의 방식으로 요청하게 되며 이러한 방식은 REST 방식 이라고 한다.

GET: 조회를 위한 용도의 요청 (queryString으로 요청한다)

PATCH(PUT): 수정을 위한 용도의 요청 (body에 값을 담아 요청한다)

POST: 등록을 위한 용도의 요청 (body에 값을 담아 요청한다)

DELETE: 삭제를 위한 용도의 요청 (queryString으로 요청한다)

PATCH와 PUT은 둘 다 수정을 위한 용도인데, 차이점으로는 PATCH는 대상의 수정되어야 할 부분만 요청하면 되지만, PUT은 변경되지 않은 정보도 요청해야한다

개발을 진행하게 되면 API명세서를 받게 되는데 위 네 가지 방식으로 만들어진 명세서가 있을 수 있고, 수정 및 삭제가 있는데도 GET/POST 두 가지 방식으로면 만들어진 명세서도 있을 수 있다.
이는 여러가지 이유가 있으나, 그중 하나로는 서버 관리자가 GET과 POST요청에 만 보안설정을 하는 경우가 있기 때문이다.(특정요청에 대해서만 서버에서 응답) 그러니 꼭 PATCH, DELETE가 없다고 잘못된 API는 아니라는 의미 이다.

API 명세서

API명세서는 프론트와 백단 간의 통신을 위한 규칙 이다.
다음을 몇가지 샘플을 예시로 들어보겠다.
URL: http://mysite.com/mypage/id/{userIdx}
Method: GET

이름 타입 자리수 필수여부
userIdx int 8 Required

위 예시는 마이페이지 접속 시 사용자의 아이디를 받아 데이터를 받아오는 명세서 이다.
대부분은 로그인 한 사용자 정보를 획득해야 하기에 사용자 아이디도 안받겠지만 특별상황에서 사용자정보를 넘겨주는 경우도 있을 수 있기에 예시로 작성하였다.
url의 마지막에 있는 userIdx와 표 영역의 이름이 같다는 것을 볼 수 있다.
타입은 데이터 형태를 의미하고, 자리수는 8자리까지 라는 의미 이다.
또한 필수 여부는 꼭 해당 값을 전달해야 한다는 의미로 이 조건에 부합하게 요청한다면 에러가 발생하게 된다.

URL: http://mysite.com/board?type={type}&id={id}&userIdx={userIdx}
Method: GET

이름 타입 자리수 필수여부
id int 10 Required
userIdx int 8

위 예시는 특정 게시글을 조회하는 데이터를 받아오는 명세서 이다.
url의 type, id, userIdx 는 위 설명과 동일하게 요청 시 필요한 항목들이다.
이번 예제는 위와는 다르게 필수여부가 체크되어 있지 않는 항목이 존재하고 이다.
이는 해당 값을 함께 요청하면 값에 따라 추가적인 데이터를 획득할 수도 있다.
(있어도 그만 없어도 그만)

URL: http://mysite.com/board?id=1
Method: DELETE

이름 타입 자리수 필수여부
id int 10 Required

이번 예시는 DELETE의 경우인데, 특정 게시글 삭제 요청 이다.
이제는 보면 파라미터 값이 하나이고, 해당 값을 필수값 이라는 의미로 해석할 수 있을 것이다.

URL: http://mysite.com/add-user
Method: POST

이름 타입 자리수 필수여부
userId String 30 Required
passwd String 30 Required
name String 10 Required
phone String 14 Required

이번 예시는 사용자 등록 API 이다.
POST 방식으로 넘겨야 하며 userId, passwd, name, phone 정보를 요창 BODY 에 담아 보내면 API서버에서 받아서DB에 쿼리하게 되는 것 이다.
일반적인 명세서에는 샘플값이나 요청 후 리턴 정보도 함께 전달하기도 한다.

마치며

처음 이 글을 작성 하였을 때는 프론트엔드 작업자 들이 과연 백엔드 시스템에 대해 얼마나 이해하고 API 명세서를 보고 얼마만큼의 이해를 하고 있을까? 라는 생각에서 작성하게 되었다.
API에 대한 이해도가 높아질수록 그만큼 일이 편해질 수 있기 때문이다.
또한 API를 호출 할 때 에러 발생 시 내가 잘못보내서 에러가 발생했는지, 혹은 서버측의 문제(명세서 오기입)로 에러가 발생 했는지에 대하여 판단을 할 수 있다면 의미있는 글이 되었다고 생각한다.


추천 글