티스토리 뷰
Part 4. REST 방식과 Ajax를 이용하는 댓글 처리
전통적인 웹 어플리케이션은 브라우저는 단순 뷰어 역할만 했다.
그러나 모바일 환경이 커지면서, 서버는 브라우저나 모바일에서 필요한 순수한 데이터만을 전달하는 API 서버의 형태로 변화하고 있다.
예를 들어 검색 API 서버는 검색 결과를 XML이나 JSON 형태로 전달하고, 브라우저나 모바일에서는 이를 가공해서 사용자에게 보여주는 방식. 이러한 환경에 대비할 수 있도록 REST 방식에 대해서 학습하고, Ajax를 이용해서 완성된 게시물에 댓글 기능을 추가한다.
Chapter 16. REST 방식으로 전환
10년간 일어난 IT 분야의 가장 큰 변화는 '모바일'이다. 모바일은 생활에 깊숙이 침투해서 생활 방식에 많은 영향을 주고 있다.
모바일 시대가 되면서 WEB 분야의 가장 큰 변화는 서버 역할의 변화라고 할 수 있다.
과거 : 서버의 데이터를 소비하는 주체가 '브라우저'라는 특정한 어플리케이션으로 제한적. 브라우저가 소화 가능한 모든 데이터를 HTML이라는 형태로 전달. 브라우저는 이를 화면에 보여주는 역할.
모바일 시대 : 앱이나 웹은 서버에서 제공하는 데이터를 소비함(셀룰러 데이터 끄면 실행되는 앱이 많이 없음). 스마트폰에서 앱(App)이라 불리는 고유한 어플리케이션을 이용해서 데이터를 소비하게 되고, 보이는 화면 역시 자신만의 방식으로 서비스함. 앱에서 서버에 기대하는 것은 자신에게 필요한 순수 데이터만을 요구하게 된것.
➡️ 서버의 역할은 순수하게 데이터에 대한 처리를 목적으로 하는 형태로 전환하고 있음
이러한 변화 속에서 웹의 URI(Uniform Resource Identifier) 의미도 변화함
(예, 과거 웹 페이지들은 페이지를 이동해서 브라우저 주소는 변화하지 않음 ==> 최근은 페이지를 이동하면 브라우저 내의 주소도 같이 이동)
URL : Uniform Resource Locator - URI의 하위 개념. '이 곳에 가면 당신이 원하는 것을 찾을 수 있습니다' 상징적 의미
URI : Uniform Resource Identifier - '당신이 원하는 곳의 주소는 여기입니다.' 현실적인 의미
REST(Representational State Transfer) : 하나의 URI는 하나의 고유한 리소스를 대표하도록 설계된다는 개념에 전송방식을 결합해서 원하는 작업을 지정함
=> '/boards/123' : 게시물 중에서 123번이라는 고유한 의미를 가지도록 설계. 이에 대한 처리는 GET, POST 방식과 같이 추가적 정보를 통해 결정
REST 관련 어노테이션
어노테이션 | 기능 |
@RestController | Controller가 REST 방식을 처리하기 위한 것임을 명시함 |
@ResponseBody | 일반적인 JSP와 같은 뷰로 전달되는 것이 아닌 데이터 자체를 전달하기 위한 용도 |
@PathVariable | URL 경로에 있는 값을 파라미터로 추출하려고 할 때 사용 |
@CrossOrigin | Ajax의 크로스 도메인 문제를 해결해주는 어노테이션 |
@RequestBody | JSON 데이터를 원하는 타입으로 바인딩 처리 |
@RestController
REST: 서버에서 전송하는 것은 HTML이 아닌, 순수한 데이터다.
기존의 Controller에서 Model에 데이터를 담아서 JSP 등과 같은 뷰(View)로 전달하는 방식이 아님
@ResetController는 메서드의 리턴 타입으로 사용자가 정의한 클래스 타입을 사용할 수 있고, 이를 JSON이나 XML로 자동 처리 가능
Json : 자바스크립트 객체 개념으로 데이터를 주고 받을 수 있도록 만든 데이터 형식. 데이터를 { }로 묶어서 '이름: 값'으로 나타낸 것. XML보다 분석도 쉽고 작업도 편함. 경량 데이터 포맷.
* gson : 구글에서 만든 Json 처리용 라이브러리
* servlet-api 3.1.0으로 올리기
* 일단 쌤이 주신 pom.xml로 저장해놓고 시간될때, dependency 뭐하는건지 하나씩 살펴보고 정리해놓기
[예제1] SampleController 클래스
produces : 이 타입의 형태를 보낸다는 것.
기존엔 HTML이 날라갔었지만, 이제는 텍스트가 날라간다.
SampleController하려면, servlet 에서 스캔 때리고, / 로 path 바꾸고, 해야함
[예제2] SampleVO 클래스
AllArgsConstructor : 매개변수 세개 다 받는 생성자 만듦
noargsconstructor : 매개변수 하나도 안받는 생성자 만듦
JSON은 크롬가지고 테스트할 것
브라우저 => 개발자도구 => network => 새로고침 => getText => 책에서 나온 부분 나옴
원래는 어디로 포워딩한다 이런 내용만 컨트롤러에 있었는데, 이제는 리턴타입을 줄 수 있음
xml로 보낼 수도 있고, .json 붙이면 json으로도 날라갈 수 있음
xml보다 json이 훨씬 낫다!
=> 개발자 도구의 response headers 에서 content type으로 이게 xml인지, json으로 날라온건지 확인할 수 있다
.json은 제일 뒤에 붙이기
ResponseEntity 타입
REST 방식으로 호출하는 경우는 데이터 자체를 전송하는 방식으로 처리되기 때문에,
데이터를 요청한 쪽에서는 정상적, 비정상적 데이터를 구분할 수 있는 확실한 방법을 제공해야 함
ResponseEntity는 데이터와 함께 HTTP 헤더의 상태 메시지 등을 같이 전달하는 용도로 사용함
HTTP 상태 코드와 에러 메시지 등을 데이터로 전달할 수 있음 => 받는 입장에서 확실하게 결과를 알 수 있음
@RestController에서 파라미터
@RestController는 기존의 @Controller에서 사용하던 일반적인 타입이나 사용자가 정의한 타입을 사용함
여기에 추가로 어노테이션을 이용함
@PathVariable : 일반 컨트롤러에서도 사용이 가능하지만 REST 방식에서 자주 사용됨. URL 경로의 일부를 파라미터로 사용할 때 이용
@RequestBody : JSON 데이터를 원하는 타입의 객체로 변환해야 하는 경우에 주로 사용
@PathVariable
REST 방식에서는 URL 내에 최대한 많은 정보를 담으려고 함
스프링 MVC에서는 @PathVariable 어노테이션을 이용해서 URL 상에 경로의 일부를 파라미터로 사용할 수 있음
예전에는 http://localhost:8080/sample?height=40&weight=50
이렇게 했다면 이제는
http://localhost:8080/sample/스트링/인트타입
이렇게 넣을 수도 있습니다!!
@PathVariable을 적용하고 싶은 경우 '{ }'를 이용해서 변수명을 지정
@PathVariable을 이용해서 지정된 이름의 변수값을 얻을 수 있음.
@RequestBody
전달된 요청(request)의 내용(body)을 이용해서 해당 파라미터의 타입으로 변환을 요구함
내부적으로 HttpMessageConverter 타입의 객체들을 이용해서 다양한 포맷의 입력 데이터를 변환할 수 잇음
@RequestBody는 말 그대로 요청한 내용을 처리하기 때문에 일반적인 파라미터 전달방식을 사용할 수 없어서 @PostMapping을 적용합니다!
GET 방식이 아닌 POST 방식으로 지정되어 있으면서 JSON 데이터를 처리하는 것을 브라우저에서 개발하려면 많은 시간과 노력이 들기 때문에 Jnit과 spring-test를 이용해서 테스트하는 방식으로 처리합니다.
SampleController.java의 conver()는 JSON으로 전달되는 데이터를 받아서 Ticket 타입으로 변환.
이를 위해 해당 데이터가 JSON이라는 것을 명시해줄 필요가 있음 ==> MockMvc의 contentType()
Gson 라이브러리 ==> Java 객체를 JSON 문자열로 변환함
--> Junit test를 돌리면 JSON 문자열이 Ticket 타입의 객체로 변환되었다는 것을 알 수 있음
혹은 다른 방식으로
Chrome의 'REST client' 확장 프로그램 중에서 'Yet Another REST client'등을 이용해서 테스트를 진행할 수도 있음.
✅ POST 방식으로 JSON을 처리하는 것이기 때문에 이런 번거로운 작업도 필요함다,,, 하지만 번거로운게 아니라고 한다는...
다양한 전송방식
REST 방식의 데이터 교환에서 가장 특이점은 GET/POST 외에 다양한 방식으로 데이터를 전달함
HTTP 전송 방식은 아래와 같은 형태로 사용됨
REST 방식은 URI와 같이 결합하므로 회원(member)라는 자원을 대상으로 전송방식을 결합하면 다음과 같은 형태가 됨
'Framework & Management > Spring' 카테고리의 다른 글
스프링 웹 프로젝트 CHAPTER18. AOP라는 패러다임 (0) | 2023.01.02 |
---|---|
11월 4일 금요일 [코드로 배우는 스프링 웹 프로젝트] - 8day(1) (0) | 2022.11.04 |
11월 2일 수요일 [코드로 배우는 스프링웹프로젝트] - 6day(1) (0) | 2022.11.02 |
11월 1일 화요일 [코드로 배우는 스프링웹프로젝트] - 5day(3) (0) | 2022.11.01 |
11월 1일 화요일 [코드로 배우는 스프링웹프로젝트] - 5day(2) (0) | 2022.11.01 |
- Total
- Today
- Yesterday
- 리스트연산자
- Format 클래스
- python
- 파이썬
- Math 클래스
- not_in
- Date 클래스
- 함수
- 포장 클래스
- FALSE
- 기본 API 클래스
- 리스트
- 문자열함수
- IndexError
- StringBuilder 클래스
- Arrays 클래스
- 프로그램
- Objects 클래스
- Calendar 클래스
- 자료형
- 딕셔너리
- StringTokenizer 클래스
- Random 클래스
- StringBuffer 클래스
- 순환할당
- 역반복문
- 요소선택
- 스레드 스케줄링
- java.time.package
- Pattern 클래스
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |