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기타
WebREST
GET정보를 가져올 때@Get@GetMappingURL을 통해 파라미터 형식으로 전달
POST정보를 전체를 변경할 때@Post@PostMappingHTTP Request Body에 변경할 내용을 포함해서 서버로 전달
PUT정보를 신규로 저장할 때@Put@PutMappingHTTP Request Body에 신규로 저장할 내용을 포함해서 서버로 전달
DELETE정보를 삭제할때@Delete@DeleteMappingURL을 통해 파라미터 형식으로 전달
PATCH정보를 부분 변경할 때@Patch@PatchMappingHTTP Request Body에 변경할 내용을 포함해서 서버로 전달
  • 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);
}

URI 규칙

규칙설명
슬래시 구분자(/)는 계층 관계를 나타내는 데 사용한다

http://api.canvas.restapi.org/shapes/polygons/quadrilaterals/squares

  • /를 통해서 리소스간 계층 관계를 표현함
URI 마지막 문자로 슬래시(/)를 포함하지 않는다

http://api.canvas.restapi.org/shapes

http://api.canvas.restapi.org/shapes/

하이픈(-)은 URI 가독성을 높이는 데 사용한다

http://api.example.restapi.org/blogs/mark-masse/entries/this-is-my-first-post

  • URI를 쉽게 읽고 해석하기 위해서 긴 URI 경로에 하이픈을 사용해서 가독성을 높일 수 있음
  • URI에서는 문장 내 공백을 하이픈으로 변경할 수 있음
밑줄(_)은 URI에 사용하지 않는다
  • 편집기 등에서 URI는 클릭이 가능한 Link 형태로 표시하여 _
URI경로에는 소문자가 적합하다
파일 확장자는 URI에 포함시키지 않는다
API에 있어서 서브 도메인은 일관성 있게 사용해야 한다
클라이언트 개발자 포탈 서브 도메인 이름은 일관성 있게 만들어야 한다






http://hungry-developer.blogspot.com/2014/06/rest-api.html

GET Method에서 파라미터 처리

파라미터 종류URL 형식Spring Annotation예시
Request Parameter/login?index=1&page=2@RequestParam
@GetMapping("login")
public ModelAndView login(@RequestParam("index") int index, 
                          @RequestParam("page") int page) {
  //...    
}
Path Variable/index/1@PathVariable
@PostMapping("index/{idx}")
@ResponseBody
public ModelAndView index(@PathVariable("idx") int index) {
  //...
}

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를 보고 알아서 동작함

웹 브라우저가 아닌 경우 개발자가 알아서 처리함

Consume과 Produce의 의미

https://www.baeldung.com/spring-requestmapping

  • 레이블 없음