[22] REST 방식과 Ajax를 이용하는 댓글처리 - REST 방식으로 전환

 

과거에는 서버의 데이터를 소비하는 주체가 '브라우저'라는 특정한 애플리케이션으로 제한적이었다면, 모바일의 시대가 되면서 앱에나 웹은 서버에서 제공하는 데이터를 소비하게 된다. 과거의 서버는 브라우저라는 하나의 대상만을 상대로 데이터를 제공했기 때문에 아예 브라우저가 소화 가능한 모든 데이터를 HTML이라는 형태로 전달하고, 브라우저는 이를 화면에 보여주는 역할을 해 왔다. 

 

스마트폰에서는 앱이라 불리는 고유한 애플리케이션을 이용해서 데이터를 소비하게 되고, 보이는 화면 역시 자신만의 방식으로 서비스하게 된다. 앱에서 서버에 기대하는 것은 완성된 HTML이 아니라 그저 자신에게 필요한 순수한 데이터만을 요구하게 되었다. 이처럼 서버의 역할은 점점 더 순수하게 데이터에 대한 처리를 목적으로 하는 형태로 진화하고 있다. 또한, 브라우저와 앱은 서버에서 전달하는 데이터를 이용해서 앱 혹은 브라우저 내부에서 별도의 방식을 통해서 이를 소비하는 형태로 전환하고 있다.

 

이러한 변화 속에서 웹의 URI(Uniform Resource Identifier) 의미도 조금 다르게 변화하기 시작했다. 예를 들어 과거에 제작된 웹페이지들의 경우 페이지를 이동하더라도 브라우저의 주소는 변화하지 않는 방식을 선호했다. 반면에 최근 웹 페이지들은 대부분 페이지를 이동하면 브라우저 내의 주소 역시 같이 이동하는 방식을 사용한다. 

 

REST는 'Representational State Transfer'의 약어로 하나의 URI는 하나의 고유한 리소스를 대표하도록 설계된다는 개념에 전송방식을 결합해서 원하는 작업을 지정한다. 예를 들어 '/board/123'은 게시물 중에서 123번이라는 고유한 의미를 가지도록 설계하고, 이에 대한 처리는 GET, POST 방식과 같이 추가적인 정보를 통해서 결정한다. 따라서 REST 방식은 다음과 같이 구성된다고 생각할 수 있다.

 

스프링은 @RequestMapping 이나 @ResponseBody와 같이 REST 방식의 데이터 처리를 위한 여러 종류의 어노테이션과 기능이 있다. REST와 관련해서 알아 두어야 하는 어노테이션들은 다음과 같다.

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

 

 

1. @RestController

 

REST 방식에서 가장 먼저 기억해야 하는 점은 서버에서 전송하는 것이 순수한 데이터라는 점이다. 기존의 Controller에서 Model에 데이터를 담아서 JSP 등과 같은 뷰로 전달하는 방식이 아니므로 기존의 Controller와는 조금 다르게 동작한다.

 

스프링 4에서부터는 @Controller 외에 @RestController 라는 어노테이션을 추가해서 해당 Controller의 모든 메서드의 리턴 타입을 기존과 다르게 처리한다는 것을 명시한다. @RestController 이전에는 @Controller 와 메서드 선언부에 @ResponseBody를 이용해서 동일한 결과를 만들 수 있다. @RestController는 메서드의 리턴 타입으로 사용자가 정의한 클래스 타입을 사용할 수 있고, 이를 JSON이나 XML로 자동으로 처리할 수 있다. 

 

1-1. 예제 프로젝트 준비

 

1) 예제를 위해 'ex03' 프로젝트를 생성한다. 기본 패키지는 org.zerock.controller 로 한다.

(스프링버전 : 5.0.7 / 이전 예제와 같이 Java 버전이나 Maven Compile 등의 버전 : 1.8 로 수정하고 프로젝트 업데이트)

 

작성된 프로젝트에는 우선적으로 JSON 데이터를 처리하기 위한 jackson-databind라는 라이브러리를 pom.xml에 추가한다. jackson-databind 라이브러리는 나중에 브라우저에 객체를 JSON이라는 포맷의 문자열로 변환시켜 전송할 때 필요하다. 

 

브라우저를 이용해서 'Maven jackson-databind'등을 검색하면 메이븐 관련 저장소를 찾을 수 있다. 

 

2) XML의 처리는 jackson-dataformat-xml 라이브러리를 이용한다. 

프로젝트 내의 pom.xml 에 -객체를 JSON/XML로 변환할 때 사용 하는 코드를 입력한다.

테스트할 때는 직접 Java 인스턴스를 JSON 타입의 문장려로 변환해야 하는 일들도 있으므로 gson 라이브러리도 추가한다.

 

3) 작성된 프로젝트의 서블릿 버전을 수정하고 Lombok 관련 설정을 추가한다. 

 

4) 테스트를 위해서 JUnit 버전을 변경하고, spring-test 관련 모듈을 추가해 둔다.

 

2. @RestController 의 반환 타입

 

스프링의 @RestController 는 특별히 기존의 @Controller 와 다른 점은 없다. 

 

1) org.zerock.controller 패키지에 SampleController를 생성한다. 

package org.zerock.controller;

import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

import lombok.extern.log4j.Log4j;

@RestController
@RequestMapping("/sample")
@Log4j
public class SampleController {

}

 

 

2-1. 단순 문자열 반환

 

@RestController는 JSP와 달리 순수한 데이터를 반환하는 형태이므로 다양한 포맷의 데이터를 전송할 수 있다. 주로 많이 사용하는 형태는 일반 문자열이나 JSON, XML등을 사용한다. 

 

1) SampleController에 문자열을 반환하려면 다음과 같은 형태로 작성한다. 

@RestController
@RequestMapping("/sample")
@Log4j
public class SampleController {
	
	@GetMapping(value = "/getText", produces = "test/plain; charset=UTF-8")
	public String getText() {
		
		log.info("MIME TYPE : " + MediaType.TEXT_PLAIN_VALUE);

		return "안녕하세요";
	}
}

 

기존의 @Controller 는 문자열을 반환하는 경우에는 JSP 파일의 이름으로 처리하지만, @RestController 의 경우에는 순수한 데이터가 된다. @GetMapping에 사용된 produces 속성은 해당 메서드가 생산하는 MIME 타입을 의미한다. 예제와 같이 문자열로 직접 지정할 수도 있고, 메서드 내의 MediaType이라는 클래스를 이용할 수도 있다. 

 

프로젝트의 실행은 이전 예제들과 같이 '/' 경로로 실행되도록 하고 브라우저를 통해서 '/sample/getText'를 호출한다. 

결과를 보면 produces의 속성값으로 지정된 'text/plain'결과가 나오는 것을 확인할 수 있다.

(그런데 나는 안녕하세요 창이 안뜨고 다운로드가 된다.. .무슨일?.. 일단 계속 진행)

 

2-2. 객체의 반환

 

객체를 반환하는 작업은 JSON이나 XML을 이용한다.

 

1) 전달된 객체를 생산하기 위해서 'org.zerock.domain' 패키지를 생성하고, SampleVO 클래스를 작성한다. 

package org.zerock.domain;

import lombok.AllArgsConstructor;
import lombok.Data;
import lombok.NoArgsConstructor;

@Data
@AllArgsConstructor
@NoArgsConstructor
public class SampleVO {
	
	private Integer mno;
	private String firstName;
	private String lastName;
}

 

SampleVO 클래스는 비어 있는 생성자를 만들기 위한 @NoArgsConstructor와 모든 속성을 사용하는 생성자를 위한 @AllArgsConstructor 어노테이션을 이용했다. 어노테이션을 통해서 생성된 결과를 보면 생성자가 여러 개 생성되는 것을 볼 수 있다. 

 

2) SampleController 에서는 SampleVO를 리턴하는 메서드를 아래와 같이 설계한다. 

	@GetMapping(value = "/getSample",
			produces = {MediaType.APPLICATION_JSON_UTF8_VALUE,
					MediaType.APPLICATION_XML_VALUE})
	public SampleVO getSample() {
		return new SampleVO(112, "스타", "로드");
	}

 

getSample()은 XML과 JSON 방식의 데이터를 생성할 수 있도록 작성되었는데, 브라우저에서 '/sample/getSample'을 호출하면 다음과 같은 화면을 볼 수 있다. 

 

위의 결과는 브라우저가 받은 데이터가 XML이기 때문에 보이는 화면이다. 개발자 도구를 통해서 살펴보면 정상적인 XML 데이터라는 것을 확인할 수 있다. 

 

동일한 메서드를 '/sample/getSample.json'을 호출하게 되면 기존과 달리 JSON 타입의 데이터가 전달되는 것을 확인할 수 있다. 

 

@GetMapping이나 @RequestMapping의 produces 속성은 반드시 지정해야 하는 것은 아니므로 생략하는 것도 가능하다. 

	@GetMapping(value = "/getSample2")
	public SampleVO getSample2() {
		return new SampleVO(113, "로켓", "라쿤");
	}

 

2-3. 컬렉션 타입의 객체 반환

 

경우에 따라서는 여러 데이터를 한 번에 전송하기 위해서 배열이나 리스트, 맵 타입의 객체들을 전송하는 경우도 발생한다. 

 

1) SampleController 에 다음과 같은 코드를 추가한다. 

	@GetMapping(value = "/getList")
	public List<SampleVO> getList(){
		return IntStream.range(1, 10).mapToObj(i -> new SampleVO(i, i+"First", i + "Last")).collect(Collectors.toList());
	}

 

getList()는 내부적으로 1부터 10 미만까지의 루프를 처리하면서 SampleVO 객체를 만들어서 List<SampleVO>로 만들어 낸다. 

 

브라우저를 통해서 '/sample/getList'를 호출하면 기본적으로는 XML 데이터를 전송하는 것을 볼 수 있다. 뒤에 확장자를 '.json'으로 처리하면 '[]' 로 싸여진 JSON 형태의 배열 데이터를 볼 수 있다. 

xml 처리

 

2) 맵의 경우에는 '키'와 '값'을 가지는 하나의 객체로 간주된다.

	@GetMapping(value = "/getMap")
	public Map<String, SampleVO> getMap(){
		
		Map<String, SampleVO> map = new HashMap<>();
		map.put("First", new SampleVO(111, "그루트", "주니어"));
		
		return map;
	}

 

Map을 이용하는 경우에는 '키'에 속하는 데이터는 XML로 변환되는 경우에 태그의 이름이 되기 때문에 문자열을 지정한다.

 

2-4. ResponseEntity 타입

 

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

 

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

 

1)  SampleController 에 다음과 같은 코드를 추가한다. 

	@GetMapping(value = "/check", params = {"height", "weight"})
	public ResponseEntity<SampleVO> check(Double height, Double weight){
		SampleVO vo = new SampleVO(0, "" + height, "" + weight);
		
		ResponseEntity<SampleVO> result = null;
		
		if(height < 150) {
			result = ResponseEntity.status(HttpStatus.BAD_GATEWAY).body(vo);
		}else {
			result = ResponseEntity.status(HttpStatus.OK).body(vo);
		}
		
		return result;
	}

 

check()는 반드시 'height'와 'weight'를 파라미터로 전달받는다. 이때 만일 'height' 값이 150 보다 작다면 502(bad gateway) 상태 코드와 데이터를 전송하고, 그렇지 않다면 200(ok) 코드와 데이터를 전송한다. 

 

'/sample/check.json?height=140&weight=60'과 같이 JSON 타입의 데이터를 요구하고, height 값을 150 보다 작게하는 경우에는 502 메시지와 데이터가 전달된다. 

 

3. @RestController에서 파라미터

 

@RestController 는 기존의 @Controller에서 사용하던 일반적인 타입이나 사용자가 정의한 타입을 사용한다. 여기에 추가로 몇 가지 어노테이션을 이용하는 경우가 있다. 

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

3-1. @PathVariable

 

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

 

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

 

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

 

REST 방식에서는 URL 자체에 데이터를 식별할 수 있는 정보들을 표현하는 경우가 많으므로 다양한 방식으로 @PathVariable이 사용된다.

 

1) SampleController 의 일부 

	@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과 같은 기본 자료형은 사용할 수 없다.

 

브라우저에서 '/sample/produck/bags/1234'로 호출하면 cat과 pid 변수의 값으로 처리되는 것을 확인할 수 있다. 

 

 

3-2. @RequestBody

 

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

 

1) 변환을 위한 예제를 위해서 'org.zerock.domain' 패키지에 Ticket 클래스를 정의한다. 

package org.zerock.domain;

import lombok.Data;

@Data
public class Ticket {

	private int tno;
	private String owner;
	private String grade;
}

 

Ticket 클래스는 tno, owner, grade를 지정한다.

 

2) Ticket을 사용하는 예제는 SampleController에 추가한다.

	@PostMapping("/ticket")
	public Ticket convert(@RequestBody Ticket ticket) {
		
		log.info("convert..............ticket" + ticket);
		
		return ticket;
	}

 

SampleController의 다른 메서드와 달리 @PostMapping 이 적용된 것을 볼 수 있는데, 이것은 @RequestBody가 말 그대로 요청한 내용을 처리하기 때문에 일반적인 파라미터 전달방식을 사용할 수 없기 때문이다.

 

작성한 convert()에 대한 테스트는 테스트 방식을 학습한 후 진행한다. 

 

4. REST 방식의 테스트

 

위와 같이 GET 방식이 아니고 POST 등의 방식으로 지정되어 있으면서 JSON 형태의 데이터를 처리하는 것을 브라우저에서 개발하려면 많은 시간과 노력이 들어간다. 

 

@RestController를 쉽게 테스트할 수 있는 방법은 주로 REST 방식의 데이터를 전송하는 툴을 이용하거나, JUnit과 spring-test를 이용해서 테스트하는 방식을 고려할 수 있다.

 

4-1. JUnit 기반의 테스트

 

JUnit을 이용하는 방식은 저번에 이용했던 방식을 그대로 이용한다. 다만 REST 방식을 이용하다 보면 JSON 데이터를 테스트해야 하므로 차이점 위주로 알아두면 좋다.

 

1) src/test/java 폴더 아래 SampleControllerTests 클래스를 작성한다. 

package org.zerock.controller;

import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.post;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;

import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.http.MediaType;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import org.springframework.test.context.web.WebAppConfiguration;
import org.springframework.test.web.servlet.MockMvc;
import org.springframework.test.web.servlet.setup.MockMvcBuilders;
import org.springframework.web.context.WebApplicationContext;
import org.zerock.domain.Ticket;

import com.google.gson.Gson;

import lombok.Setter;
import lombok.extern.log4j.Log4j;

@RunWith(SpringJUnit4ClassRunner.class)

//Test for Controller
@WebAppConfiguration

@ContextConfiguration({"file:src/main/webapp/WEB-INF/spring/root-context.xml",
	"file:src/main/webapp/WEB-INF/spring/appServlet/servlet-context.xml"})

@Log4j
public class SampleControllerTests {
	
	@Setter(onMethod_ = {@Autowired})
	private WebApplicationContext ctx;
	
	private MockMvc mockMvc;
	
	@Before
	public void setup() {
		this.mockMvc = MockMvcBuilders.webAppContextSetup(ctx).build();
	}
	
	@Test
	public void testConvert() throws Exception{
		
		Ticket ticket = new Ticket();
		ticket.setTno(123);
		ticket.setOwner("Admin");
		ticket.setGrade("AAA");
		
		String jsonStr = new Gson().toJson(ticket);
		
		log.info(jsonStr);
		
		mockMvc.perform(post("/sample/ticket")
				.contentType(MediaType.APPLICATION_JSON)
				.content(jsonStr))
				.andExpect(status().is(200));
	}
}

 

testConvert()는 SampleController에 작성해둔 convert() 메서드를 테스트 하기 위해서 작성했다. SampleController의 convert()는 JSON으로 전달되는 데이터를 받아서 Ticket 타입으로 변환한다. 이를 위해서는 해당 데이터가 JSON 이라는 것을 명시해 줄 필요가 있다. 

 

MockMvc는 contentType()을 이용해서 전달하는 데이터가 무엇인지를 알려줄 수 있다. 코드 내의 Gson 라이브러리는 Java의 객체를 JSON 문자열로 변환하기 위해서 사용한다. 

 

위의 코드를 실행하면 다음과 같이 전달되는 JSON 문자열이 Ticket 타입의 객체로 변환된 것을 볼 수 있다. 

 

4-2. 기타 도구

 

JUnit을 이용하는 방식 외에도 Tomat을 구동한다면 REST 방식을 테스트할 수 있는 여러가지 도구들이 존재한다. 만일 Mac이나 리눅스 등을 이용한다면 간단히 curl(https://curl.haxx.se/) 같은 도구를 이용할 수도 있고, Java나 각종 언어로 개발된 라이브러리들을 이용할 수 있다.

 

최근에는 브라우저에서 직접 REST 방식을 테스트할 수 있는 도구들이 꽤 많이 있다. Chrome 브라우저 앱스토어로 이동해서 'REST client'로 검색하면 꽤 많은 크롬 확장 프로그램을 볼 수 있다. 

 

이중 'Restlet Client'를 이용해서 테스트를 진행한다.

 

Tomcat을 실행하였다면 'Reslet Client'에서는 'GET/POST/...'등의 방식으로 접근이 가능하다. 요청의 내용 역시 오른쪽의 화면처럼 원하는 내용을 전달할 수 있다.

 

5. 다양한 전송방식

 

REST 방식의 데이터 교환에서 가장 특이한 점은 기존의 GET/POST 외에 다양한 방식으로 데이터를 전달한다는 점이다. HTTP 의 전송방식은 아래와 같은 형태로 사용된다. 

작업	전송방식
Create	POST
Read	GET
Update	PUT
Delete	DELETE

 

REST 방식은 URI와 같이 결합하므로 회원이라는 자원을 대상으로 전송방식을 결합하면 다음과 같은 형태가 된다.

작업	전송방식	URI
등록	POST	/members/new
조회	GET	/members/{id}
수정	PUT	/members/{id} + body {json 데이터 등)
삭제	DELETE	/member/{id}

 

POST 방식도 그렇지만 PUT, DELETE 방식은 브라우저에서 테스트하기가 쉽지 않기 때문에 개발 시 JUnit이나 'Restlet Client' 등과 같은 도구를 이용해서 테스트하고 개발해야만 한다.