목차 |
---|
...
REST(Representational State Transfer)
REST가 오기전까지 관련 기술에 대한 이해
- 과거의 HTTP는 HTML을 표현하는데에만 사용
- Rich Internet Application(RIA)이 나오면서 HTML 페이지의 내용만 변경하는 기술을 적용하려는 움직임이 있었음
- 이 시기에 비동기로 HTTP 프로토콜을 호출해서 데이터 등을 받아오는 기술이 대두. 이것을 Ajax라고 하였음. 이때부터 Web의 기술이 발전하기 시작하였으며 웹의 사용성이 급격하게 향상되었음.
- 하지만 Ajax는 표준도 아니고 그냥 활용 기술이었으며 이 시기에는 여전히 legacy HTML 기술과 Ajax가 공존하여 지저분한 상태의 웹이 많았음. 또한 이 시기에 JavaScript가 새로운 대세 언어가 될 것처럼 되었고 jQuery가 이때 모두가 써야하는 프레임워크로 등극
- 그 이후 HTTP 프로토콜을 이용한 REST 방식의 새로운 아키텍처가 등장하여 웹 기술에서 대표 표준으로 활용을 하게 됨
- 그리고 JavaScript에서 문자열이면서 직접 JavaScript Object로 변환이 가능한 JSON 포맷이 각광 받게 됨
REST 아키텍처에 적용되는 6가지 제한
- 클라이언트/서버 구조 : 일관적인 인터페이스로 분리되어야 한다
- 무상태(Stateless) : 각 요청 간 클라이언트의
...
- 컨텍스트가 서버에 저장되어서는 안 된다
- 캐시 처리 가능(Cacheable) : WWW에서와 같이 클라이언트는 응답을 캐싱할 수 있어야 한다.
- 잘 관리되는 캐싱은 클라이언트-서버 간 상호작용을 부분적으로 또는 완전하게 제거하여 scalability와
...
- performance를 향상시킨다.
- 계층화(Layered System) : 클라이언트는 보통 대상 서버에 직접 연결되었는지, 또는 중간 서버를 통해 연결되었는지를 알 수 없다. 중간 서버는 로드 밸런싱 기능이나 공유 캐시 기능을 제공함으로써 시스템 규모 확장성을 향상시키는 데 유용하다.
- Code on demand (optional)
...
- : 자바 애플릿이나 자바스크립트의 제공을 통해 서버가 클라이언트가 실행시킬 수 있는 로직을 전송하여 기능을 확장시킬 수 있다.
- 인터페이스 일관성 : 아키텍처를 단순화시키고 작은 단위로 분리(decouple)함으로써 클라이언트-서버의 각 파트가 독립적으로 개선될 수 있도록 해준다.
REST 인터페이스이 원칙
원칙 | 세부 설명 |
---|---|
자원의 식별 | 요청 내에 기술된 개별 자원을 식별할 수 있어야 한다. 웹 기반의 REST 시스템에서의 URI의 사용을 예로 들 수 있다. 자원 그 자체는 클라이언트가 받는 문서와는 개념적으로 분리되어 있다. 예를 들어, 서버는 데이터베이스 내부의 자료를 직접 전송하는 대신, 데이터베이스 레코드를 HTML, XML이나 JSON 등의 형식으로 전송한다. |
메시지를 통한 리소스의 조작 | 클라이언트가 어떤 자원을 지칭하는 메시지와 특정 메타데이터만 가지고 있다면 이것으로 서버 상의 해당 자원을 변경·삭제할 수 있는 충분한 정보를 가지고 있는 것이다. |
자기서술적 메시지 | 각 메시지는 자신을 어떻게 처리해야 하는지에 대한 충분한 정보를 포함해야 한다. 예를 들어 MIME type과 같은 인터넷 미디어 타입을 전달한다면, 그 메시지에는 어떤 파서를 이용해야 하는지에 대한 정보도 포함해야 한다. 미디어 타입만 가지고도, 클라이언트는 어떻게 그 내용을 처리해야할 지 알 수 있어야 한다. 메시지를 이해하기 위해 그 내용까지 살펴봐야 한다면, 그 메시지는 자기서술적이 아니다. 예를 들어, 단순히 "application/xml"이라는 미디어 타입은, 실제 내용을 다운로드 받지 않으면 그 메시지만 가지고는 무엇을 해야할지에 대해 충분히 알려주지 못한다. |
애플리케이션의 상태에 대한 엔진으로서 하이퍼미디어 | 만약에 클라이언트가 관련된 리소스에 접근하기를 원한다면, 리턴되는 지시자에서 구별될 수 있어야 한다. 충분한 콘텍스트 속에서의 URI를 제공해주는 하이퍼텍스트 링크의 예를 들 수 있겠다. |
REST의 주요 목표
- 구성 요소 상호작용의 규모 확장성(scalability of component interactions)
- 인터페이스의 범용성 (Generality of interfaces)
- 구성 요소의 독립적인 배포(Independent deployment of components)
- 중간적 구성요소를 이용해 응답 지연 감소, 보안을 강화, 레거시 시스템을 인캡슐레이션 (Intermediary components to reduce latency, enforce security and encapsulate legacy systems)
HTTP Method
HTTP Method | 용도 | Spring Annotation | 기타 | |
---|---|---|---|---|
Web | REST | |||
GET | 정보를 가져올 때 | @Get | @GetMapping | URL을 통해 파라미터 형식으로 전달 |
POST | 정보를 변경할때 | @Post | @PostMapping | HTTP Request Body에 변경할 내용을 포함해서 서버로 전달 |
PUT | 정보를 신규로 저장할 때 | @Put | @PutMapping | HTTP Request Body에 신규로 저장할 내용을 포함해서 서버로 전달 |
DELETE | 정보를 삭제할때 | @Delete | @DeleteMapping | URL을 통해 파라미터 형식으로 전달 |
PATCH | @PatchMapping |
- REST 이전에는 POST 방식으로 데이터를 변경(신규 추가, 변경, 삭제)하는 작업을 수행함
- PUT, DELETE는 REST 이전에 보안 위배로 등록되어 활용할 수 없었으며 현재도 막는 기업들이 있음
다음은 HTTP Method를 지원하는 Spring Framework의 Controller 코드이다.
코드 블럭 | ||||
---|---|---|---|---|
| ||||
@GetMapping("/{id}") public ResponseEntity<?> getBazz(@PathVariable String id){ return new ResponseEntity<>(new Bazz(id, "Bazz"+id), HttpStatus.OK); } @PostMapping public ResponseEntity<?> newBazz(@RequestParam("name") String name){ return new ResponseEntity<>(new Bazz("5", name), HttpStatus.OK); } @PutMapping("/{id}") public ResponseEntity<?> updateBazz(@PathVariable String id, @RequestParam("name") String name) { return new ResponseEntity<>(new Bazz(id, name), HttpStatus.OK); } @DeleteMapping("/{id}") public ResponseEntity<?> deleteBazz(@PathVariable String id){ return new ResponseEntity<>(new Bazz(id), HttpStatus.OK); } |
...
파라미터 종류 | URL 형식 | Spring Annotation | 예시 | |||||||
---|---|---|---|---|---|---|---|---|---|---|
Request Parameter | /login?index=1&page=2 | @RequestParam |
| |||||||
Path Variable | /index/1 | @PathVariable |
|
Request Body의 형식
형식 | 유형 | 설명 |
---|---|---|
텍스트 | JSON | REST 방식의 출현, AJAX의 출현을 JSON 형식이 현재 가장 대세 과거 JSON은 UI에서 사용하던 기술이나 이제는 Server 간 데이터 송수신에서도 JSON을 사용 |
XML | 과거 XML은 이기종 시스템(Server)간 데이터 송수신시 가장 완벽한 포맷으로 사용 XSD 등의 스키마를 통해 데이터의 구조 및 유효성이 보장 XML은 파싱에 과도한 비용이 소요되고 무겁다는 인식으로 최근은 사용하지 않음 | |
PLAIN | JSON, XML도 엄밀하게 따져보면 PLAIN TEXT 어떤 것이든 PLAIN TEXT로 내용을 담을 수 있음 | |
바이너리 | IMAGE | 이미지 파일을 송수신할 때 Request & Response Body에는 이미지 바이너리 데이터가 포함 파일의 포맷은 HTTP Header를 통해서 전달되며 웹 브라우저는 헤더를 보고 어떤 포맷인지를 확인한 후 바이너리를 로딩하여 처리 |
기타 미디어 | MP4 등도 Request & Response Body에 포함이 가능하며 HTTP Header를 보고 결정 웹 브라우저인 경우 HTTP Header를 보고 알아서 동작함 웹 브라우저가 아닌 경우 개발자가 알아서 처리함 |
...