사이드 프로젝트 Yaksok을 진행하면서 처음으로 RESTAPI를 기반으로 프론트앤드와 백엔드의 업무가 완전히 분리된 개발 경험을 하고 있습니다.
모두 열정은 가득하지만 경험은 많지 않아 삽질의 연속이었는데 여정을 요약하면 아래와 같습니다.
열정 가득한 우리는 무엇이 필요한지도 모른 채 열정을 표출하며 각자 할 줄 아는 것들을 해나가기 시작했습니다. FE는 BE가 잘 데이터를 보내주겠지, BE는 FE가 데이터를 잘 받겠지라는 공상을 하며 각자 할 줄 아는 것들부터 먼저 해나갔습니다.
그러던 중, 뒤늦게 우리의 작업하는 모습을 본 3년차 개발자 분께서 보시고는... 이게 무슨일인가? 라고 외치는 사태가 벌어졌습니다. 동료분의 진단은 RESTAPI 명세서가 필요하다는 부분이었습니다. 프론트와 백의 긴밀한 소통은 기본적으로 이러한 명세서로 이루어져야만 하는 것인데 이런 인터페이스가 없으니 방향을 못잡고 있다는 것이었습니다. 우리 모두 용감했지만 경험이 없었던 개발과정을 복기 하며 명세서 작성이 들어갔습니다.
https://wonit.tistory.com/454
명세서 작성은 GoolgeDocs로 이루어졌습니다. 동시 작성이 가능하다는 점에서 모두 함께 빠르게 작성해 나갈 수 있었습니다. 각자 작성을 시작했고, 의문이 남는 부분은 회의 시간에 해소해 나갔습니다. 그렇게 API문서의 작성이 완료되었을 때 의문이 들었습니다.
RESTAPI 명세서를 작성하였지만, 프론트엔드에서는 그래서 어떤 요청을 보내야 되는 것인가에 대한 물음이 여전히 들려왔습니다. API의 구조는 알겠으나 세부적으로 어떤 값을 보내주어야 되는지에 대해서 명확하지 않아 어렵게 느껴진다는 것이었습니다. 서로의 경험이 부족하여 이런 풀리지 않는 의문이 있구나 하는 생각이 먼저 들었지만 한편으로는 어떤 개발자가 와도 이해할 수 있고, 바로 코드를 구현해 나갈 수 있는 환경과 방법이 더 좋은 방향이라는 생각이 머리를 떠나지 않았습니다.
그러한 의문점을 갖고 있었는데 오늘 나름의 개선할 수 있는 방법에 대한 힌트를 찾게 되었습니다.
해당 개념은 HATEOAS 였습니다. HATEOAS는 Hypermedia As The Engine of Application State의 약자로 결국 Link라는 키 값에 프론트에서 요청할 수 있는 API나 여러 페이지 및 리소스들의 경로는 함께 제공한다는 개념입니다. 사실 RESTful에 있어서 어느 정도의 입지를 갖고 있는 개념이지만 보통 메서드와 URI 네이밍 규칙에 가려 잘 고려되지 않는 개념이었습니다.
HATEOAS를 구현한 HAL-JSON은 아래와 같습니다.
백엔드에서는 응답을 보낼 때, 프론트에서 필요할 수 있는 모든 요청 URI를 links라는 속성에 담아 함께 보내줍니다. 프론트에서는 쉽게 해당 URI를 담고 있는 key를 사용하여 다음 요청을 보낼 수 있게 하는 구조입니다.
모든 URI를 보내주어야 된다는 사실에서 오는 공수가 있기 때문에 아주 보편적으로 사용되지는 않는 것 같습니다. 현재 진행중인 프로젝트에서도 사용할지 말지에 대한 고민도 더 필요할 듯 해 보입니다. 하지만 프론트와 백의 소통에 있어서 좋은 가이드가 될 수 있는 기능이라는 생각이 들었습니다.
{
"data":
{ // HAL JSON의 리소스 필드
"id": 1000,
"name": "게시글 1",
"content": "HAL JSON을 이용한 예시 JSON" },
"_links": { // HAL JSON의 링크 필드
"self": { "href": "http://localhost:8080/api/article/1000"}, // 현재 api 주소
"profile": { "href": "http://localhost:8080/docs#query-article"}, // 해당 api의 문서
"next": { "href": "http://localhost:8080/api/article/1001"}, // article 의 다음 api 주소
"prev": { "href": "http://localhost:8080/api/article/999"} // article의 이전 api 주소
}
}