[REST스러운 게 대체 뭘까?] 예전에 이제 막 python, flask 공부를 마치고 처음으로 REST API를 개발하는 업무를 맡게 되었을 때 HTTP 메소드는 POST로 통일하고 url을

[REST스러운 게 대체 뭘까?] 예전에 이제 막 python, flask 공부를 마치고 처음으로 REST API를 개발하는 업무를 맡게 되었을 때 HTTP 메소드는 POST로 통일하고 url을 함수 이름처럼 표현해서 백엔드를 구현했었다. 그렇게 생애 첫 개발 업무를 끝내고 REST에 대해서 공부를 하고는 잘못 개발하고 있었다는 것을 깨닫고 REST스러움을 굉장히 따지는 개발자가 되었다. 그런데 요즘에는 REST스러움을 따지는 게 의미가 있나 의문이 든다. 꼭 PUT 대신에 PATCH를 써야 할까? url에 리소스를 표현하기 위해서 노력해야 할까? 이런걸 고려해서 얻는 게 뭘까? 오히려 고려하면 종교전쟁이 되기만 하지 궁극의 해결책을 내기가 참 어려운 것 같다. 같은 리소스를 가져오는 UI지만 필요한 데이터 형식이 다른 경우 over-fetching을 고려하여 UI마다 따로 api를 만들어도 되고 over-fetching을 감수하고 하나의 api로 만들어버릴 수도 있다. CRUD로 표현하기 어려운 행동은 어떻게 표현할 지 애매하다. 이런 의사결정에 있어서 REST가 주는 도움이 뭐가 있을까? 나는 별로 없다고 생각한다. 차라리 만능 POST 메소드에 url을 함수 이름처럼 사용하는 게 나을 것 같다는 생각이 든다. 이런 고민이 들던 와중에 반가운 사례를 접했다. 바로 노션이다. 노션 공개 api는 REST를 지키려고 노력했지만 내부에서만 사용되는 api의 경우 REST를 전혀 지키기 않았다. 노션을 브라우저에서 실행한 후 개발자 도구로 HTTP 요청을 확인해보면 POST 메소드에 url을 함수처럼 사용하였다. 퍼블릭으로 공개된 api의 경우에는 약속된 언어를 지키는 것이 좋을 수 있지만 프라이빗한 api의 경우에는 REST를 굳이 지키지 않아도 될 것 같다. 현재 개발하고 있는 프로젝트에서는 REST를 지키고 있긴 하다. 다만 REST 순수주의자가 되지 않으려고 노력하고 있다. 그리고 graphql의 컨셉을 일부 차용하여 UI 의존성을 줄일 수 있도록 REST API를 디자인하여 구현을 시도하고 있다.