[개인공부] REST 방식

Walter Mitty·2023년 2월 5일

개인공부

목록 보기

40/41

REST 방식으로의 전환

과거의 서버는 브라우저라는 하나의 대상만을 상대로 데이터를 제공했으므로 브라우저가 소화 가능한 모든 데이터를 HTML 형태로 전달했고, 브라우저는 이걸 화면에 보여주는 역할을 해왔다.
그러나 모바일 시대가 되면서 앱(App)이라는 고유한 애플리케이션을 이용해서 데이터를 다루게 되었다. 앱에서 서버에 기대하는 것은 완성된 HTML이 아니라 필요한 순수 데이터를 요구했으므로 서버의 역할이 점점 더 순수한 데이터 처리를 목적으로 하는 형태로 진화됐다.

브라우저와 앱은 서버에서 전달하는 데이터를 이용해서 앱 혹은 브라우저 내부에서 별도의 방식을 통해 이를 소비하는 형태로 전환

URI의 의미 변화

과거에는 페이지를 이동하더라도 브라우저의 주소는 변화하지 않는 방식을 선호했다. 반면 최근 웹페이지들은 페이지를 이동하면 브러우저 내의 주소 역시 같이 이동하는 방식을 사용한다.

URL(Uniform Resource Locator)

URI의 하위개념

"이 곳에 가면 당신이 원하는 것을 찾을 수 있습니다" 라는 상징적 의미

URI(Uniform Resource Identifier)

'자원의 식별자'라는 의미로 사용된다

"당신이 원하는 곳의 주소는 여기입니다"라는 현실적이고 구체적인 의미

URI의 'I'는 데이터베이스의 PK와 같은 의미로 사용된다고 할 수 있다.

REST

Representational State Transfer

하나의 URI는 하나의 고유한 리소스(Resource)를 대표하도록 설계된다는 개념 + 전송방식
예) '/boards/123'은 게시물 중에서 123번이라는 고유한 의미를 가지도록 설계
- 이에 대한 처리는 GET, POST 방식과 같이 추가적인 정보를 통해서 결정된다

REST 방식의 구성

URI + GET/POST/PUT/DELETE/....

REST와 관련해서 알아두어야 하는 어노테이션들

스프링에서 REST 방식의 데이터 처리를 위한 여러 종류의 어노테이션과 기능이 있다
예)@RequestMapping, @ResponseBody

어노테이션	기능
@RestController	Controller가 REST 방식을 처리하기 위한 것임을 명시
@ResponseBody	일반적인 JSP와 같은 뷰로 전달되는 게 아니라 데이터 자체를 전달하기 위한 용도
@PathVariable	URL 경로에 있는 값을 파라미터로 추출하려고 할 때 사용
CrossOrigin	Ajax의 크로스 도메인 문제를 해결해주는 어노테이션
RequestBody	JSON 데이터를 원하는 타입으로 바인딩 처리

@RestController

REST 방식에서 가장 먼저 기억해야하는 점은 서버에서 전송하는 것이 순수한 데이터라는 점이다.

@RestController : @Controller + @ResponseBody
Controller의 모든 메서드의 리턴 타입을 기존과 다르게 처리한다는 것을 명시
- 메서드의 리턴 타입을 사용자가 정의한 클래스 타입을 사용할 수 있다
- JSON이나 XML로 자동으로 처리할 수 있다.

ResponseEntity 타입

REST 방식으로 호출하는 경우는 화면 자체가 아니라 데이터 자체를 전송하는 방식으로 처리한다. 따라서 데이터를 요청한 쪽에서는 정상적인 데이터인지 비정상적인 데이터인지를 구분할 수 있는 확실한 방법을 제공해야만 한다.

ResponseEntity는 데이터와 함께 HTTP Header의 상태 메시지 등을 같이 전달하는 용도로 사용
- HTTP의 상태 코드와 에러 메시지 등을 함께 데이터를 전달할 수 있기 때문에 받는 입장에서는 확실하게 결과 알 수 있음

@RestController에서 파라미터

@RestController는 기존의 @Controller에서 사용하던 이반적인 타입이나 사용자가 정의한 타입(클래스)를 사용한다.
추가로

@PathVariable: 일반 컨트롤러에서도 사용이 가능하지만 REST 방식에서 자주 사용됨
- URL 경로의 일부를 파라미터로 사용할 때 이용
@RequestBodt: JSON 데이터를 원하는 타입의 객체로 변환해야 하는 경우에 주로 사용

@PathVariable

REST 방식에서는 URL에 최대한 많은 정보를 담으려고 노력한다. 예전에는 '?'뒤에 추가되는 쿼리 스트링(query string)이라는 형태로 파라미터를 이용해서 전달되던 데이터들이 REST 방식에서는 경로의 일부로 차용되는 경우가 많다.

스프링 MVC에서는 @PathVariable 어노테이션을 이용해서 URL 상에 경로의 일부를 파라미터로 사용할 수 있다.
예)

http://localhost:8080/sample/{sno}
http://localhost:8080/sample/{sno}/page/{pno}

위의 URL에서 '{ }'로 처리된 부분은 컨트롤러의 메서드에서 변수로 처리가 가능하다.
따라서 @PathVariable은 '{ }'의 이름을 처리할 때 사용한다.

@GetMapping("product/{cat}/{pid}")
public String[] getPath(@PathVariable("cat") String cat, @PathVariable("pid") Integer pid) {
  	return new String[] {"category: " + cat, "productid: " + pid };

처럼,

@PathVariable을 적용하고 싶을 때는 '{ }'를 이용해서 변수명을 지정
@PathVariable을 이용해서 지정된 이름의 변숫값을 얻을 수 있다.

주의!!
값을 얻을 때에는 int, double 같은 기본 자료형은 사용할 수 없다.

@RequestBody

@RequestBody는 전달된 요청(request)의 내용(body)을 이용해서 해당 파라미터의 타입으로 변환을 요구한다.
내부적으로 HttpMessageConverter 타입의 객체들을 이용해서 다양한 포맷의 입력 데이터를 변환할 수 있다.
대부분의 경우 JSON 데이터를 서버에서 보내서 원하는 타입의 객체로 변환하는 용도로 사용, 그러나 경우에 따라서는 원하는 포맷의 데이터를 보내고 이를 해석해서 원하는 타입으로 사용하기도 한다.

다양한 전송 방식

작업	전송방식	URI 예)
Create	POST	/members/new
Read	GET	/members/{id}
Update	PUT	/members/{id}+body(json 데이터 등)
Delete	DELETE	/members/{id}

—-

@PathVariable은 default 값을 지정할 수 없다->오류날 수 있음

Optional<Integer>currentPage로 처리

Optional은 null값을 처리해줄 수 있는 자바의..점(?)이다
currentPage라는 PathVariable이 있는지 없는지 확인할 수 있다.

if(currentPage.isPresent()){
    int cpp = currentPage.get();
    sysout(“검색할 페이지:“+cp)
}

@PathVarialble은 Optional로 처리(전달되지 않을 값 처리)

currentPage.ifPresent((cp)->{
    System.out.println(“검색할 페이지:“ + cp);
});

ifPresent() : consumer 타입의 메서드는 lambda 표현식을 요구한다. ()-> 이거이거

Controller에 delete메서드 만들고,
- RemoveException 쓸거라서 만들러가기
- ControllerAdvice로 떠넘기기 위해 RemoveException 도 추가해주기

@PutMapping("{boardNum}")
public ResponseEntity<?> modify(@PathVariable int boardNum, String boardTitle, String boardContent) {
	return new ResponseEntity<>(HttpStatus.OK);
}