REST API, 정말 최선일까? 크로키의 API 설계 고민과 대안

2012년부터 REST API를 사용했지만, HTTP 동사와 여러 리소스 처리의 어려움을 느낌

로그인/로그아웃 API와 같은 경우 REST API 스타일로 표현하기 어려워 non-REST API를 사용

RPC 스타일 API와 GraphQL을 도입하여 REST API의 한계를 극복하려 시도

REST API의 한계: HTTP 동사, 복잡한 쿼리

REST API는 HTTP 메서드를 통해 자원(Resource)을 표현하지만, 로그인/로그아웃과 같은 액션은 적절한 메서드 매핑이 어렵다. 구체적으로 여러 리소스를 한 번에 가져오거나, 요청 파라미터에 따라 다른 결과를 반환해야 하는 경우 REST API의 단일 책임 원칙을 위반하게 된다. 따라서 RPC 스타일 API나 GraphQL과 같은 대안을 고려하게 된다.

RPC vs GraphQL: API 설계의 새로운 선택지

REST API의 대안으로 RPC 스타일 API는 단순하고 명확한 API 설계를 가능하게 한다. GraphQL은 클라이언트가 원하는 데이터만 요청할 수 있어 네트워크 사용량 감소에 효과적이다. 반면, RPC는 REST API보다 유연성이 떨어지고, GraphQL은 학습 곡선이 존재하며, 서버 구현이 복잡해질 수 있다.

API 설계, 상황에 맞는 기술 선택

API 설계는 서비스의 요구사항과 트레이드오프를 고려하여 결정해야 한다. REST API는 단순한 CRUD 작업에 적합하지만, 복잡한 쿼리나 액션에는 RPC 또는 GraphQL을 고려해야 한다. 따라서 마이크로서비스 간 통신에는 RPC, 클라이언트-서버 통신에는 GraphQL을 적용하는 등, 상황에 맞는 기술을 선택하는 것이 중요하다.