요청 매핑부분을 자세히 공부하였다.

 

package hello.springmvc.basic.requestmapping;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class MappingController {

    private Logger log = LoggerFactory.getLogger(getClass());

    @RequestMapping("/hello-basic")
    public String helloBasic(){
        log.info("helloBasic");
        return "ok";
    }

}

 

매핑 정보

@RestController

  @Controller는 반환 값이 String이면 뷰 이름으로 인식된다. 그래서 뷰를 찾고 뷰가 랜더링 된다.

  @RestController는 반환 값으로 뷰를 찾는 것이 아니라, HTTP 메시지 바디에 바로 입력한다.

   따라서 실행 결과로 OK메시지를 받을 수 있다. @ResponseBody와 관련이 있다.

 

@RequestMapping("/hello-basic")

  /hello-basic  URL 호출이 오면 이 메서드가 실행되도록 매핑한다.

  대부분의 속성을 배열로 제공하므로 다중 설정이 가능하다.{"/hello-basic" , "/hello-go"}

 

Postman으로 테스트 해보았다.

 

둘다 허용

다음 두가지 요청은 다른 URL이지만, 스프링은 다음 요청들을 같은 요청으로 매핑한다.

매핑 : /hello-basic

URL 요청 : /hello-basic, /hello-basic/

 

HTTP 메서드

@RequestMapping에 method 속성으로 HTTP 메서드를 지정하지 않으면 HTTP 메서드와 무관하게 호출된다.

모두허용 GET, HEAD, POST, PUT, PATCH, DELETE

package hello.springmvc.basic.requestmapping;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class MappingController {

    private Logger log = LoggerFactory.getLogger(getClass());

    @RequestMapping(value = "/hello-basic", method = RequestMethod.GET)
    public String helloBasic(){
        log.info("helloBasic");
        return "ok";
    }

}

Post로 보내면 오류(405)가 발생한다.

 

다음 코드를 보면

HTTP 메서드를 축약한 애노테이션을 사용하는 것이 더 직관적이라는 것을 알 수 있다.

@GetMapping(value = "/mapping-get-v2")
    public String mappingGetV2() {
        log.info("mapping-get-v2");
        return "ok";
    }

 

PathVariable(경로 변수) 사용

  @GetMapping("/mapping/{userId}")
    public String mappingPath(@PathVariable("userId") String data){
        log.info("mappingPath userId={}", data);
        return "ok";
    }

최근 HTTP API는 다음과 같이 리소스 경로에 식별자를 넣는 스타일을 선호한다.

/mapping/userA

/user/1

 

@RequestMapping은 URL 경로를 템플릿화 할 수 있는데, @PathVariable을 사용하면 매칭 되는 부분을 

편리하게 조회할 수 있다.

 

@PathVariable의 이름과 파라미터 이름이 같으면 생략할 수 있다.

 

    @GetMapping("/mapping/users/{userId}/orders/{orderId}")
    public String mappingPath(@PathVariable String userId, @PathVariable Long
            orderId) {
        log.info("mappingPath userId={}, orderId={}", userId, orderId);
        return "ok";
    }

이런식으로 설계하는 것이 요즘 많이 쓰는 방식이라고 한다.

 

	@GetMapping(value = "/mapping-param", params = "mode=debug")
		public String mappingParam() {
 			log.info("mappingParam");
 			return "ok";
}

파라미터에 조건을 거는 방식 또한 있다.

파라미터로 mode=debug라는 것이 있어야 호출이 된다.

 

@GetMapping(value = "/mapping-header", headers = "mode=debug")
public String mappingHeader() {
 log.info("mappingHeader");
 return "ok";
}

헤더에 또한 조건을 줄 수 있다.

 

@PostMapping(value = "/mapping-consume", consumes = "application/json")
public String mappingConsumes() {
 log.info("mappingConsumes");
 return "ok";
}

미디어 타입 역시 조건을 걸 수 있다. content-type기반

 

@PostMapping(value = "/mapping-produce", produces = "text/html")
public String mappingProduces() {
 log.info("mappingProduces");
 return "ok";
}

컨트롤러가 생산해내는 컨텐트 타입을 조건을 걸 수 도있다.

클라이언트의 요청 정보에 받아들일 수 있는 타입을 보고(Accept 헤더)를 기반으로 매핑한다.

+ Recent posts