rest api에서 같은 DB Table에 대해 서로 다른 필드를 받을때, 각각 하나의 엔드포인트로 작성하는게 맞을까요?

Question

게시글 페이지로 예를들어,
리스트 페이지에서는 author, title, views 
게시글 상세페이지에서는 모든 필드를 반환해주는 엔드포인트가 있습니다.

지금은 두개의 엔드포인트라서 괜찮지만,  필요한 요구사항이 생길때 마다 각각 하나의 엔드포인트를 만들어주는 것이 맞을까요?

달레 · Answer

REST API 설계에 대해서 고민하고 계신 것으로 보이며 이 것은 백엔드 개발에 있어서 상당히 중요한 문제입니다.

말씀하신 방식으로 새로운의 필드의 조합이 나타날 때 마다 새로운 엔드포인트를 추가하다보면 엔드포인트의 수가 지나치게 많아질 수 있고 API 유지보수가 점점 힘들어 질 수 있습니다. 뿐만 아니라 엔드포인트를 추가할 때 마다 좋은 URL을 생각해내는 것도 은근히 골치가 아플 수 있죠.

따라서 일반적으로 조회할 DB 테이블이 동일하고 응답에 포함해야 할 필드만 달라질 수 있는 경우에는 하나의 엔드포인트로 처리하는 경우가 많습니다. 이를 위해서는 보통 해당 엔드포인트가 쿼리 파라미터를 통해서 필요한 필드를 명시할 수 있도록 설계를 합니다.

예를 들어, 아래과 같이 쿼리 스트링을 명시하지 않으면 요청을 하면 모든 필드를 포함한 게시글을 반환하고요.

```
GET /posts/{id}
```

반면에 다음과 같은 쿼리 스트링과 함께 요청을 하면 author, title, views 필드만 포함한 게시글을 반환합니다.

```
GET /posts/{id}?fields=author,title,views
```

이런 식으로 유연하게 REST API 설계를 하면 각 엔드포인트의 재사용성이 높아져서 유지보수가 용이해집니다. 백엔드 코드도 크게 복잡해지지 않습니다. 쿼리 파라미터를 읽어서 DB 테이블을 조회할 때 적절히 넘겨주기만 하면 되니까요.

마지막으로 추가 조언을 드리자면... 너무 특정 클라이언트 입장에서 REST API를 설계하시기 보다는 해당 REST API가 관리하고 있는 데이터를 중심으로 접근해보시라고 말씀드리고 싶습니다. REST API의 사용성이나 확장성, 유지보수성을 고려하시는데 도움이 될 것입니다.