REST(Representational State Transfer)

자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)르르 주고 받는 모든 것을 의미한다.

1. 자원(resource)의 표현(representation)에 의한 상태 전달
   • 자원 : 해당 소프트웨어가 관리하는 모든것 ex) 문서, 그림, 데이터
   • 자원의 표현 : 그 자원을 표현하기 위한 이름 ex) DB의 학생 정보가 자원일때 students를 자원의 표현이라고 한다.
2. 상태(정보) 전달
   • 데이터가 요청되어지는 시점에서 자원의 상태(정보)를 전달
   • JSON혼은 XML를 통해 데이터를 주고 받는것이 일반적이다
3. HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일
4. REST는 네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나

REST의 구체적인 개념

HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고 HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미

• REST는 자원 기반의 구조(ROA)설계의 중심에 Resource가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐를 의미
• 웹 사이트의 이미지, 텍스트 db내용등의 모든 자원에 고유한 ID인 HTTP URL를 부여한다
• CRUD Operation
  • Create(POST)
  • Read(GET)
  • Update(PUT, PATCH)
  • Delete(DELETE)
  • Head : 정보조회

장점

• HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출할 필요가 없다
• HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 할께 가져갈 수 있게 해준다.
• HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다
• Hypermedia API 의 기본을 충실히 지키면서 범용성을 보장한다.
• REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
• 여러가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.
• 서버와 클라이언트의 역할을 명확하게 분리한다.

단점

• 표준이 존재하지 않는다.
• 사용할 수 있는 메소드가 4가지 밖에 없다.
  • HTTP Method 형태가 제한적이다.
• 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 값이 왠지 더 어렵게 느껴진다.
• 구형 브라우저가 아직 제대로 지원해주지 못하는 부분이 존재
  • PUT, DELETE를 사용하지 못하는 점
  • pushState를 지원하지 않는 점

REST가 필요한 이유

• 애플리케이션 분리 및 통합
• 다양한 클라이언트의 등장
• 최근의 서버 프로그램은 다양한 브라우저와 안드로이폰, 아이폰과 같은 모바일 디바이스에서도 통신을 할 수 있어야 한다.
• 이러한 멀티 플랫폼에 대한 지원을 위해 서비스 자원에 대한 아키텍처를 세우고 이용하는 방법을 모색한 결과 REST에 관심을 가지게 되었다.

명세서 작성 방법

첫페이지에 url정보와 기능을 적고

각 url별 header, body, request 등등 값을 정의한 면세서 작성