나는 몇개의 팀 프로젝트를 진행하면서 백엔드 팀원이 만들어 제공해주는 API를 사용해보기도 했고, 최근 프로젝트를 통해 직접 API를 작성해보기도 했다. 직접 만들거나 사용할 때는 아무 생각이 없었는데, 문득 이런 생각이 들었다.
내가 프로젝트에서 REST API를 사용했나?
더 이전으로 돌아가서는 "백엔드 팀원이 제공해준 API는 REST API였나?" 라는 생각과 "나는 REST API에 대해서 제대로 알고는 있나?" 라는 생각까지 하게 되었다. 분명 배웠는데, 막상 머릿속에서 이게 무엇인지 설명하려하니 아무것도 생각이 나지 않는 것이었다.
API
API(application programming interface 애플리케이션 프로그래밍 인터페이스, 응용 프로그램 프로그래밍 인터페이스)는 컴퓨터나 컴퓨터 프로그램 사이의 연결이다. 일종의 소프트웨어 인터페이스이며 다른 종류의 소프트웨어에 서비스를 제공한다.
위키백과에 적혀있는 API의 설명이다. 인터페이스는 어떤 두 장치 사이에서 정보를 교환하기 위한 수단이나 방법을 말하므로, API는 소프트웨어끼리 정보를 주고받기 위한 수단인 것이다.
HTTP
HTTP는 웹 브라우저나 어플리케이션과 같은 클라이언트가 서버와 통신하기 위한 프로토콜(컴퓨터끼리 데이터를 교환하는 방법을 정의하는 규칙 체계)을 말한다.
그러니까 HTTP API란 HTTP 형식에 맞추어 소통하는 API라는 뜻이 된다.
REST API
REST(REpresentational State Transfer) API는 HTTP의 장점을 최대한 활용할 수 있는 아키텍처이다.
정리해보자면 API > HTTP API > REST API 의 느낌인 것 같다.
이 REST API를 작성하기 위해서는 네가지의 가이드라인을 준수해야 한다.
- 자원의 식별
- 메서드를 통한 리소스 조작
- 자기서술적 메세지
- 애플리케이션의 상태에 대한 엔진으로서 하이퍼미디어(HATEOAS)
1번과 2번은 지키기 어렵지 않지만, 3번과 4번은 지키기가 쉽지 않기도 하고 규칙을 준수하기 위한 개발 비용 대비 효과가 뛰어난 것도 아니라 거의 1, 2번만 지킨 HTTP API가 REST API와 같은 의미로 사용되고 있다고 한다.
그렇다면 나는 HTTP를 잘 활용했나?
근데 REST API의 의미가 좁혀졌다고 해서 내가 HTTP를 잘 활용했냐 하면 그것도 100% 자신이 있지는 않았다.
HTTP를 잘 활용하기 위해서는 URI로 자원을 표현하는 데에 집중하고, 자원의 상태(행위)에 대한 정의는 HTTP METHOD로 표현해야 하는데, URI로 자원을 제대로 표현하지 않았기 때문이다.
나는 일정을 작성하고 불러올 수 있는 달력 페이지에서 다음과 같이 API를 설계했다.
GET /calendar
POST /calendar
PATCH /calendar
DELETE /calendar
메서드를 보면 달력 페이지에서 무엇을 불러오거나 수정하는 것과 같은 행위를 추측할 수 있지만, 어떤 것을 불러오는지 알 수 없다. 이 코드를 작성할 때는 "이 페이지에서 다룰 데이터가 이거 하나밖에 없으니 URI에 id값 같은것을 명시하지 않아도 되겠지? 그냥 body에 id값을 넣어주자." 라고 생각했지만, 끝나고나서 다시 생각해보니 이 페이지에 다른 기능을 추가하게 된다면 이 URI를 그대로 사용할 수 없을 것 같아 보였다. 기능이 여러개 있다면 이 URI만 봐서는 도대체 달력 페이지에서 무엇을 가져오는지 파악이 안되기 때문이다.
GET /calendar/plan
POST /calendar/plan
PATCH /calendar/plan/:id
DELETE /calendar/plan/:id
그래서 이런 식으로 바꿔주었다. GET 요청은 한달 기간의 일정을 전부 불러와주는 요청이라 따로 id값을 넣어주진 않았다. 이렇게 적어주니 확실히 어떤 것들을 가져오는 지 알 수 있어서 보기가 편해서 좋다.
참고 자료
