일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- d
- 스프링부트핵심가이드
- 목록처리
- iterator
- Kernighan의 C언어 프로그래밍
- resttemplate
- 자바편
- 네트워크 설정
- 구멍가게코딩단
- 자료구조와 함께 배우는 알고리즘 입문
- 서버설정
- 자료구조와함께배우는알고리즘입문
- 친절한SQL튜닝
- 처음 만나는 AI수학 with Python
- 코드로배우는스프링웹프로젝트
- 데비안
- network configuration
- 이터레이터
- ㅒ
- baeldung
- 페이징
- 코드로배우는스프링부트웹프로젝트
- GIT
- 스프링 시큐리티
- 티스토리 쿠키 삭제
- 처음 만나는 AI 수학 with Python
- 선형대수
- /etc/network/interfaces
- 리눅스
- 알파회계
- Today
- Total
bright jazz music
Rest방식 본문
모바일 시대가 되면서 WEB분야의 가장 큰 변화는 서버 역할의 변화라고 할 수 있다. 과거에는 서버의 데이터를 소비하는 주체가 '브라우저'라는 특정한 애플리케이션으로 제한적이었다면, 모바일의 시대가 되면서 앱이나 웹은 서버에서 제공하는 데이터를 소비하게 된다. 과거의 서버는 브라우저라는 하나의 대상만을 상대로 데이터를 제공했기 때문에 아예 브라우저가 소화 가능한 모든 데이터를 HTML이라는 형태로 전달하고, 브라우저는 이를 화면에 보여주는 역할을 해 왔다.
스마트폰에서는 앱(App)이라 불리는 고유한 애플리케이션을 이용해서 데이터를 소비하게 되고, 보이는 화면 역시 자신만의 방식으로 서비스하게 된다. 앱에서 서버에 기대하는 것은 완성된 HTML이 아니라 그저 자신에게 필요한 순수한 데이터만을 요구하게 되었다. 이처럼 서버의 역할은 점점 더 순수하게 데이터에 대한 처리를 목적으로 하는 형태로 진화하고 있다. 또한, 브라우저와 앱은 서버에서 전달하는 데이터를 이용해서 앱 혹은 브라우저 내부에서 별도의 방식을 통해서 이를 소비하는 형태로 전환하고 있다.
이러한 변화 속에서 웹은 URI(Uniform Resource Identifier) 의미도 조금 다르게 변화하기 시작했다. 예를 들어 과거에 제작된 웹페이지들의 경우 페이지를 이동하더라도 브라우저의 주소는 변화하지 않는 방식을 선호했다. (가장 대표적인 사이트가 네이버의 카페와 같은 경우이다.).
반면 최근의 웹페이지들은 대부분 페이지를 이동하면 브라우저 내의 주소 역시 같이 이동하는 방식을 사용한다.
REST는 'Representational State Transfer'의 약어로 하나의 URI는 하나의 고유한 리소스(Resource)를 대표하도록 설계된다는 개념에 전송방식을 결합해서 원하는 작업을 지정한다. 예를 들어 '/boards/123'은 게시물 중에서 123번이라는 고유한 의미를 가지도록 설계하고, 이에 대한 처리는 GET, POST 방식과 같이 추가적인 정보를 통해서 결정한다. 따라서 REST 방식은 다음과 같이 구성된다고 생각할 수 있다.
URI + GET/POST/PUT/DELETE/...
*URL(Uniform Resource Locator)은 엄밀히 말해 URI(Uniform Resource Identifier)의 하위 개념이다. URI는 자원의 식별자라는 의미로 사용된다. URL은 "이곳에 가면 당신이 원하는 것을 찾을 수 있다"와 같은 상징적인 의미가 더 강하다. URI는 '당신이 원하는 곳의 주소는 여기이다"와 같이 좀 더 현실적이고 구체적인 의미가 있다. URI의 'I'는 마치 DB의 PK와 같은 의미로 사용된다고 할 수 있다.
스프링은 @RequestMapping이나 @ResponseBody와 같이 REST 방식의 데이터 처리를 위한 여러 종류의 어노테이션과 기능이 있다. REST와 관련해서 알아두여야 하는 어노테이션들은 아래와 같다.
어노테이션 | 기능 |
@RestController | Controller가 REST 방식을 처리하기 위한 것임을 명시한다. |
@ResponseBody | 일반적인 JSP와 같은 뷰로 전달되는 게 아니라 데이터 자체를 전달하기 위한 용도 |
@PathVariable | URL 경로에 있는 값을 파라미터로 추출하려고 할 때 사용 |
@CrossOrigin | Ajax의 크로스 도메인 문제를 해결해주는 어노테이션 |
@RequestBody | JSON 데이터를 원하는 타입으로 바인딩 처리 |
@RestController
"REST방식에서 가장 먼저 기억해야 하는 점은 서버에서 전송하는 것이 순수한 데이터"라는 점이다. 기존의 Controller에서 Model에 데이터를 담아서 JSP 등과 같은 view로 전달하는 방식이 아니므로 기존의 Controller와는 조금 다르게 동작한다.
스프링 4에서부터는 @Controller 외에 @RestController라는 어노테이션을 추가해서 해당 Controller의 모든 메서드의 리턴 타입을 기존과 다르게 처리한다는 것을 명시한다. @RestController 이전에는 @Controller와 메서드 선언부에 @ResponseBody를 이용해서 동일한 결과를 만들 수 있다. @RestController는 메서드의 리턴 타입으로 사용자가 정의한 클래스 타입을 사용할 수 있고, 이를 JSON이나 XML로 자동으로 처리할 수 있다.
'Framework > Spring' 카테고리의 다른 글
JpaRepository + 페이징, 쿼리메소드 (0) | 2022.06.23 |
---|---|
JPA 인터페이스 생성 + CRUD 테스트 (insert, findById, getOne, getReferenceById save, deleteById) (0) | 2022.06.12 |
JPA 활용 + 클래스 생성 및 테이블 생성 (0) | 2022.06.09 |
리스트 또는 배열을 파라미터로 전달할 때의 처리 (0) | 2022.04.07 |
추상클래는 왜 반드시 (0) | 2021.12.02 |