#2 HTTP API 요청 매핑, 헤더 조회

서버에 요청을 보내는 API 규칙은 만들기 나름이겠지만, 보통은 REST API를 많이 구현한다.

 

# RESTful API란?

REpresentational State Transfer '대표적인 상태 전달'

REST란 웹에 존재하는 모든 자원에 고유한 URI를 부여해서 사용하는 방법을 말한다. 

RESTful API란 HTTP 메서드를 REST하게 사용하는 아키텍쳐 스타일이다. 기존의 메서드들 (Post, Get, Put, Delete)를 용도에 따라 나누고 해당 자원에 대한  CRUD를 적용시키는 방법이다.

• 자원(Resource) : URI로 표현, 모든 자원에는 고유한 ID가 존재한다.
• 행위(Verb) : HTTP Method 사용, GET, POST등으로 서버에 해당 자원에 대한 조작을 요청한다.
• 표현 : REST에서 자원은 json, xml, text, rss등 여러 형태로 표현하여 주고 받을 수 있다.

장점	- HTTP 인프라를 그대로 활용한다. - 즉 HTTP를 사용하는 모든 플랫폼에서 사용 가능하다. - REST 메시지가 직관적이라 읽고 사용하기 쉽다. - 서버와 클라이언트의 역할을 명확하게 분리할 수 있다.
단점	- 표준이 존재하지 않는다. 강제할 수 없다. - 사용할 수 있는 메서드가 4개 밖에 없다.

 

@ REST의 특징

• Uniform Interface (인터페이스 일관성)
  - URI로 지정한 리소스에 대한 조작이 통일되고, 요청 메시지만으로 의미를 파악할 수 있다.
   -특정 언어나 기술에 종속되지않는다. HTTP를 이용하여 모든 플랫폼에 사용 가능하다.
  
  
• 명확한 서버-클라이언트 구조
  - 자원이 있는 쪽이 Server, 자원을 요청하는 쪽이 Client가 된다.
  - Server: API를 제공하고 비즈니스 로직 처리 및 저장을 책임진다.
  - Client: 사용자 인증이나 context(세션, 로그인 정보) 등을 직접 관리하고 책임진다.
  
  
• Stateless (무상태)
  - HTTP 자체가 무상태성을 갖기도 하고, 클라이언트의 상태를 URI로 받기 때문에 서버에 저장할 필요가 없다.
  - 즉 서버는 각각의 요청을 별개의 것으로 인식하고 처리한다.
  
  
• Cacheable (캐시 가능)
  무상태성 덕분에 트랜잭션이 발생하지 않고, 대량의 요청을 효율적으로 캐시하여 성능을 향상 시킬 수 있다.
  
  
• Layered System (계층화)
  REST Server를 다중 계층으로 구성하기 쉽다.
  - API 서버는 비즈니스 로직을 처리하고, 그 앞 단에 프록시, 보안, 로드밸런싱, 암호화등을 추가하기 쉽다.
  - 즉 확장성이 뛰어나다.

 

 

---

# API 요청 매핑하기

회원 관리 API로 예를 들면 아래와 같다. 이를 스프링 MVC로 매핑해보자.

• 회원 목록 조회: GET /users
• 회원 등록: POST /users
• 회원 조회: GET /users/{userId}
• 회원 수정: PATCH /users/{userId}
• 회원 삭제: DELETE /users/{userId}

@RestController
@RequestMapping("/mapping/users")
public class MappingClassController {
    /**
     * GET /mapping/users
     */
    @GetMapping
    public String users() {
        return "get users";
    }

    /**
     * POST /mapping/users
     */
    @PostMapping
    public String addUser() {
        return "post user";
    }

    /**
     * GET /mapping/users/{userId}
     */
    @GetMapping("/{userId}")
    public String findUser(@PathVariable String userId) {
        return "get userId=" + userId;
    }

    /**
     * PATCH /mapping/users/{userId}
     */
    @PatchMapping("/{userId}")
    public String updateUser(@PathVariable String userId) {
        return "update userId=" + userId;
    }

    /**
     * DELETE /mapping/users/{userId}
     */
    @DeleteMapping("/{userId}")
    public String deleteUser(@PathVariable String userId) {
        return "delete userId=" + userId;
    }
}

 

---

# HTTP 헤더 조회

mapping된 메서드는 필요한 파라미터를 골라서 사용할 수 있다.

자바 인터페이스로 정해진 것이 아니라 스프링 프레임워크에서 유연하게 사용하도록 만들어주기 때문이다. 참고로 MultiValueMap은 Map과 유사한데, 하나의 key에 여러값을 받을 수 있는 자바 컬렉션이다.

 

* 로그가 필요하면 @Slf4j을 사용하자. 이는 롬복 태그인데, 사용하면 아래와 같이 선언해준다. 

private static final org.slf4j.Logger log = 
org.slf4j.LoggerFactory.getLogger(RequestHeaderController.class);

 

추가적으로 사용한 @어노테이션

• @RequestHeader MultiValueMap headerMap : 모든 HTTP 헤더를 가져온다.
• @RequestHeader("host") String Host : 특정 HTTP 헤더를 이름으로 가져온다.
• @CookieValue("myCookie", required = false) : 특정 쿠키를 조회. required는 필수 값 여부(없으면 예외 발생)

@Slf4j
@RestController
public class RequestHeaderController {
    @RequestMapping("/headers")
    public String headers(HttpServletRequest request,
                          HttpServletResponse response,
                          HttpMethod httpMethod,
                          Locale locale,
                          @RequestHeader MultiValueMap<String, String>
                                  headerMap,
                          @RequestHeader("host") String host,
                          @CookieValue(value = "myCookie", required = false)
                                  String cookie
    ) {
        log.info("request 정보 ={}", request);
        log.info("response 정보 ={}", response);
        log.info("httpMethod 정보 ={}", httpMethod);
        log.info("locale 정보 ={}", locale);
        log.info("headerMap 정보 ={}", headerMap);
        log.info("header host 정보 ={}", host);
        log.info("myCookie 정보 ={}", cookie);
        return "ok";
    }
}