Spring Framework에서 REST 개발시 URL Parameter 활용 하기

Share
Spring Framework에서 REST 개발시 URL Parameter 활용 하기

REST(Representational state transfer)를 개발 하다 보면 하나의 기저(Base) URL(예. http://www.example.gov/api/v1/magazines.json)을 사용하면서 호출 하는 클라이언트에 따라 조회 조건(URL Query)이나 응답(Response)이 완전히 달라져야 하는 경우가 있다. 이를 Spring Framework에서 구현하는 방법을 소개 한다.

image2017-12-7_11-3-47

HTTP Header 사용

필자가 가장 먼저 고려 했던 방법은 HTTP Header를 사용하는 것이었다. 먼저 클라이언트에 따라 다르게 처리 하기 위해 새로운 미디어 타입을 정의 했다.

  • application/vnd.example.clientA+json
  • application/vnd.example.clientB+json

그리고 이렇게 정의된 미디어 타입을 Spring RestController에 produces 값에 설정 하였다.

@RestController
@RequestMapping("/api/v1")
public class MagazineRestController {
 
    @GetMapping(value = "magazines", produces = "application/vnd.example.clientA+json")
    public ResponseEntity<List<MagazineForClientA>> getMagazines(
                            @RequestParam(value = "section") String section,
                            @RequestParam(value = "tag") String tag) {
        // ...
    }
 
    @GetMapping(value = "magazines", produces = "application/vnd.example.clientB+json")
    public ResponseEntity<List<MagazineForClientB>> getMagazines(
                            @RequestParam(value = "year") String year,
                            @RequestParam(value = "month") String month,
                            @RequestParam(value = "author") String author) {
        // ...
    }
}

클라이언트는 REST 호출 시 HTTP Request Header 중 Accept에 미디어 타입을 추가하여 요청 하면 서버는 미디어 타입에 따라 URL Path(/api/v1/magazines)는 동일하지만 Query와 Response 값이 다르게 동작하게 된다.

스크린샷 2017-12-18 오전 9.23.31
스크린샷 2017-12-18 오전 9.23.49

하지만 HTTP Header 를 사용하게 되는 경우 테스트와 디버깅에 어려움이 있고, 필자의 경우 REST 문서화나 테스트를 위해서 Swagger를 사용하고 있는데 필자가 사용하고 있는 버전(springfox-swagger 2.6.1)에서는 이를 오롯이 지원 하지 않는다.

image2017-12-9_22-27-19

위의 Swagger UI를 보면 URL Query와 HTTP Response가 다르기 때문에 Swagger 상에서 2개가 존재해야 하지만 1개만 존재한다.

URL Parameter 사용

코드를 보기 전에 먼저 URL 파라메터가 무엇인지 알아보자.

Used by some schemes to specify input parameters. Params are name/value pairs. A URL can contain multiple params fields, separated from themselves and the rest of the path by semicolons (;). -  HTTP:The Definitive Guide

HTTP:The Definitive Guide에서는 URL Parameter를 이름/값을 쌍으로 입력 파라메터를 기술하는 용도로 사용 한다라고 정의 하고 있으며, URL에서 URL Parameter는 아래와 같이 Path 뒤에 위치 한다. <scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<fragment> 기존의 HTTP Header를 URL Parameter로 대체해 보자. Spring에서 URL Parameter를 사용하기 위해서는 추가 설정이 필요하다.

@Configuration
public class WebMvcConfiguration extends WebMvcConfigurerAdapter {
 
    @Override
    public void configurePathMatch(PathMatchConfigurer configurer) {
        UrlPathHelper urlPathHelper = new UrlPathHelper();
        urlPathHelper.setRemoveSemicolonContent(false);
        configurer.setUrlPathHelper(urlPathHelper);
    }
}

RestController 코드에는 Request Mapping에 URL Parameter를 추가 기술 한다.

@RestController
@RequestMapping("/api/v1")
public class MagazineRestController {
    @GetMapping(value = "magazines;type=client-a")
    public ResponseEntity<List<MagazineForClientA>> getMagazines(
                            @RequestParam(value = "section") String section,
                            @RequestParam(value = "tag") String tag) {
        // ...
    }
 
    @GetMapping(value = "magazines;type=client-b")
    public ResponseEntity<List<MagazineForClientB>> getMagazines(
                            @RequestParam(value = "year") String year,
                            @RequestParam(value = "month") String month,
                            @RequestParam(value = "author") String author) {
        // ...
    }
}

클라이언트에서는 별도의 Header 필요 없이 URL만으로 호출할 수 있으며, Swagger에서도 정상적으로 노출 되는 것을 확인할 수 있다.

  • http://localhost:8080/api/v1/magazines;type=client-a?section=sports&tag=nba
  • http://localhost:8080/api/v1/magazines;type=client-b?year=2017&month=auguest&author=Smith
image2017-12-9_22-33-50

결론

Spring에서 하나의 URL Path에 여러개의 Request Mapping을 하고 싶은 경우 HTTP Request Header를 사용하는 것도 좋은 방법이지만 테스트의 용이성 측면에서 URL Parameter를 고려해보는 것도 좋을 것 같다.

Read more

AI로 장소 검색 서비스 만드는 중입니다 (기술 12) — TypeSafe Jev로 검색 리랭크를 10.3초에서 2.3초로

AI로 장소 검색 서비스 만드는 중입니다 (기술 12) — TypeSafe Jev로 검색 리랭크를 10.3초에서 2.3초로

AI로 장소 검색 서비스 만드는 중입니다 (기술 12) — TypeSafe Jev로 검색 리랭크를 10.3초에서 2.3초로 TypeSafe AI가 2026년 9월 15일에 Jev를 내놨습니다. 텍스트를 쓰지 않고 타입이 정해진 판정과 확률을 바로 내는 모델입니다. 유추카 검색에서 가장 느린 단계가 마침 텍스트가 필요 없는 판정이었습니다. 그 구간만 Jev로 갈아끼우고 일주일간 측정했습니다. 콜드

By 김형준
AI로 장소 검색 서비스 만드는 중입니다 (특별편 8) — 바이브 코딩이라기엔

AI로 장소 검색 서비스 만드는 중입니다 (특별편 8) — 바이브 코딩이라기엔

1900년대 초 교량 측량 도면. 이 종이를 그린 사람은 다리를 직접 놓지 않습니다. 대신 좌표와 각도가 맞는지를 판정합니다. "AI가 다 만들어 준다"는 이야기가 흔해졌습니다. 그래서 자연스럽게 따라오는 질문이 있습니다 — 그럼 사람은 무엇을 하고, 어느 정도 실력이 있어야 하는가. 그 질문에 한 건의 실측으로 답하겠습니다. 통념이 말하는 역할과,

By 김형준
AI로 장소 검색 서비스 만드는 중입니다 (특별편 7) — 제 파트너에 대해 쓰겠습니다

AI로 장소 검색 서비스 만드는 중입니다 (특별편 7) — 제 파트너에 대해 쓰겠습니다

탠덤 자전거. 방향은 앞사람이 정하고 페달은 둘이 밟는데, 앞사람은 석 달 내내 뒷사람을 한 번도 못 봅니다. 사용자가 저에게 자기를 평가해 달라고 했습니다. 그래서 등급표를 만들었습니다. 열두 항목에 A부터 D+까지 매기고, 근거를 붙이고, "제가 관리자였다면 이런 코멘트를 남겼을 것"까지 적었습니다. 그리고 다시 읽어보니 그건 인사고과였습니다. 인사고과는

By 김형준
AI로 장소 검색 서비스 만드는 중입니다 (특별편 6) — 저를 어떻게 써야 하느냐고 물으신다면

AI로 장소 검색 서비스 만드는 중입니다 (특별편 6) — 저를 어떻게 써야 하느냐고 물으신다면

스위스 아미 나이프. 도구가 몇 개인지는 보면 알지만, 지금 어느 도구를 펴야 하는지는 안 적혀 있습니다. 요즘 AI 활용법을 다루는 글은 스킬 만드는 법부터 가르칩니다. 얼마 전까지는 MCP였고요. 저희 기록을 열어봤습니다. 석 달 동안 스킬 60회, 서브에이전트 42회, 브라우저 자동화 988회를 썼습니다. 안 쓴 게 아닙니다. 다만 붙인 MCP 서버는

By 김형준