REST .... ?

REST의 정의

• 대표적인 상태 전달의 약자
• 월드 와이드 웹(www)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍쳐의 한 형식
  • REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍쳐 스타일
  • REST는 네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나
• 구체적인 개념
  • HTTP URI 를 통해 자원을 명시하고, HTTP Method를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미
  • 즉, REST는 자원 기반의 구조 설계의 중심에 resource가 있고, HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐를 의미
  • 웹 사이트의 이미지, 텍스트 DB 내용등의 모든 자원에 고유한 ID인 HTTP URI를 부여함

장점

• 여러가지 서비스 디자인에 생길 수 있는 문제를 최소화해줌
• Hypermedia API의 기본을 충실히 지키면서 범용성을 보장해줌
• HTTP 프로토콜 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해줌

단점

• 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URI보다 Header 값이 어렵게 느껴짐
• 구형 브라우저가 아직 제대로 지원해주지 못하는 부분이 존재
  • PUT, DELETE를 사용 못하는 점
  • pushState를 지원하지 않는 점 (history.pushState → 뒤로가기)

특징

• Server-Client
• Stateless
• Cacheable
• Layered system
• Code On Demand (option)
• Uniform Interface (인터페이스 일관성)

필요한 이유

• 애플리케이션 분리 및 통합
• 다양한 클라이언트의 등장
• 즉, 최근의 서버 프로그램은 다양한 브라우저와 모바일 디바이스에서도 통신을 할 수 있어야함
• MSA 분산 서비스와 관련되어있음 (api call을 통한 데이터 처리)

구성 요소

• 자원(Resource) : URI
  • 모든 자원에 고유한 id가 존재하고, 이 자원은 Server에 존재
  • 자원을 구별하는 id는 'localhost:8080/user/:userid'와 같은 HTTP URI
  • Client는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청
• 행위(Verb) : Http Method
  • HTTP 프로토콜의 Method를 사용
  • GET, POST, PUT, DELETE, HEAD 와 같은 메서드를 제공함
• 표현 (Representation Of Resource)
  • Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답표현(Representation)을 보냄
  • REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타내어 질 수 있음
  • 옛날에는 XML이었지만 현대에는 JSON으로 표현하고 있음

---

REST API

• API는 해당 애플리케이션을 제어할 수 있게 해주는 중간 인터페이스(연결점)
• 예를 들어, 키보드라는 인터페이스를 통해 하드웨어에 입력해주는 기능을 해주는 것과 같음
• 영화 조회 서비스 API를 통해 특정 명령만 내리면 해당 애플리케이션이 그에 맞는 기능을 수행

정의

• REST를 기반으로 서비스 API를 구현한 것
• 최근 OpenAPI, 마이크로 서비스등을 제공하는 업체 대부분은 REST API를 제공

특징

• REST 기반으로 시스템을 분산해 확장성과 재사용을 높여 유지보수 및 운용을 편리하게 할 수 있음
• REST는 HTTP 표준을 기반으로 구현하므로, HTTP를 지원하는 프로그래밍 언어로 클라이언트, 서버를 구현할 수 있음

기본 설계 규칙

• URI는 자원을 표현해야 함
  • resource는 명사
  • 소문자 복수형
  • GET /members/1
• 자원에 대한 행위는 HTTP Method으로 표현함
  • URI에 HTTP Method가 들어가면 안됨
    • GET /members/delete/1 → DELETE /members/1
  • 어떤 행위나 행동에 관해서 동사 표현이 들어가면 안됨
    • GET /members/insert/2 → POST /members/2
    • GET /members/show/1 → GET /members/1

REST API 설계 규칙

• 슬래시 구분자(/)는 계층 관계를 나타내는데 사용
• URI 마지막 문자로 슬래시(/)를 포함하지 않음
• 대소문자 구분으로서 kebab case 형식을 사용
  Kebab case : 모두 소문자로 표현하며 단어와 단어 사이를 대시(-)를 이용하여 구분, 스프링의 yml 파일이나 url 주소에서 사용
• 밑줄(_) 은 URI에 사용하지 않음
  • 밑줄은 보기 어렵거나 밑줄 때문에 문자가 가려지기도 하므로 가독성을 위해 사용하지 않음
• URI 경로에는 소문자가 적합
• URI 경로에는 대문자 사용은 피하도록 함
• 파일 확장자는 URI에 포함하지 않음
  • REST API에서는 메시지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URI 안에 포함시키지 않음
  • 리소스 간에는 연관 관계가 있는 경우
    • /리소스명/리소스 ID/관계가 있는 다른 리소스 명
    • ex ) GET :/users/{userid}/devices (일반적으로 소유 'has'의 관계를 표현할 때)
  • :id는 하나의 특정 resource를 나타내는 고유값
    • ex ) student를 생성하는 route:POST /students
    • ex ) id = 12인 student를 삭제하는 route:DELETE /students/12

---

RESTful

개념

• RESTful은 일반적으로 REST라는 아키텍쳐를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어임
  • 즉, REST 원리를 따르는 시스템은 RESTful이란 용어로 지칭됨
• RESTful은 REST를 REST 답게 쓰기 위한 방법으로, 누군가 공식적으로 발표하는 것이 아님

목적

• 이해하기 쉽고 사용하기 쉬운 REST API 만드는 것
• RESTful API를 구현하는 근본적인 목적이 퍼포먼스 향상에 있는게 아니라, 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는게 주 동기이니, 퍼포먼스가 중요한 상황에서는 굳이 RESTful API를 구현할 필요는 없음

RESTful 하지 못한 경우

• ex ) CRUD 기능을 모두 POST로만 처리하는 API
• ex ) route에 resource, id 외의 정보가 들어가는 경우 (/students/updateName)