새로운 내용을 공부할 때
새로운 내용의 공부를 시작할 때 용어의 정의를 이해하지 못하거나 정확하게 알지 못한다면 그 용어가 포함된 문장을 이해하지 못합니다.
작은 단어 하나가 내용을 이해하지 못하게 하기 때문에 용어를 정확하게 이해하는 것이 중요합니다.

1 분 소요

프로젝트를 진행하면서 PathVariableQueryString에 대해서 고민을 했습니다.

  • GET api/v1/user/{id}: PathVariable 방식
  • GET api/v1/user?id={id} :QueryString 방식

RESTful 원칙에서 URI에 대한 식별자는 리소스(Resource)를 명확하게 식별하는 데 사용합니다.

PathVariable 방식

경로 파라미터로 식별자를 사용하는 경우에는 리소스의 ID(식별자)를 경로에 포함시켜 특정 리소스를 지정합니다. 이때 경로 파라미터는 리소스의 고유 식별자가 됩니다.

GET /user/{id}

여기서 {id}는 일반적으로 데이터베이스의 기본 키(Primary key)와 연관됩니다.

따라서 저 식별자와 HTTP Method를 사용하여 엔드포인트를 만들 수 있습니다.

GET /user/{id}
POST /user/{id}
put /user/{id}

특정 자원을 가져올 때 사용하며, 자원을 정렬하거나 필터링을 목적으로 사용하지 않습니다.

식별자는 시간이 지나도 변하지 않는 속성을 가지고 있어야 합니다.

QueryString 방식

쿼리스트링에 넣어야하는 항목은 리소스를 필터링, 정렬, 검색, 페이징처리을 위한 정보가 들어갑니다.

RESTful API의 리소스(URI)에는 리소스의 상태가 들어가면 안되지만 쿼리 스트링에는 상태나 속성에 따라 결과를 좁히는 목적으로 사용합니다.

GET /product?isAddCart=&color=red

보안

단순한 게시판이나 상품 정보를 조회하는 경우 URL에 번호 식별자가 들어가도 상관없다고 생각됩니다.

GET /api/v1/products/123456

URL은 사용자가 직접 수정하여 서버에 요청할 수 있고 리소스 식별자나 쿼리 스트링은 HTTPS 프로토콜 환경이라도 암호화되지 않습니다. 브라우저의 주소 창에 노출될 수 있으며, 웹 서버 로그에도 저장될 수 있습니다.

따라서 민감한 회원 식별자나 그외 식별자는 쿼리스트링이나 URL에 포함되지 않도록 해야합니다.

정리

회원 조회와 같이 개인정보는 리소스 식별자나 쿼리 스트링이 아닌 인가 방식을 사용하도록 설계해야 한다고 생각합니다.

식별자가 외부에 노출되거나 변경후 서버 요청을 해도 상관없는 경우에만 URL에 식별자가 들어가야 한다고 생각합니다.

댓글남기기