[WEB] RESTful API - REST 6가지 원칙, URI와 URL

RESTful API

• 월드 와이드 웹(WWW)와 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식으로
• 자원을 정의하고 자원에 대한 주소를 지정하는 방법 전반에 대한 패턴
• REST(Representational State Transfer) 
  • 기본 원칙을 성실히 지킨 디자인을 RESTful 하다고 표현할 수 있다.
  • 하나의 아키텍처로 표현 가능하다.
  • Resource Oriented Architecture : API 설계의 중심에 자원(Resource)이 있고, HTTP Method를 통해 자원을 처리하도록 설계하는 것

 

URL(Uniform Resource Locator) : 실제 위치, 컴퓨터 네트워크에서 리소스가 어디에 있는지 알려주기 위한 규약 

URI(Uniform Resource Identifier) : 자원의 위치 + 자원에 대한 고유 식별자, 특정 리소스를 식별하는 통합 자원 식별자

REST 구성

• 자원(resource) 
  • 표현 방법 : HTTP URI
  • ex. http://localhost:8080/main
  • 명사로 표현
• 행위(Verb) : 자원의 행위
  • 표현 방법 : HTTP METHOD
  • GET, POST, PUT, DELETE
• 표현(Representations)  : 응답 자원의 상태
  • 표현 방법 : HTTP Message Pay Load
  • ex. JSON, XML

 

REST 6가지 원칙

• Uniform Interface(유니폼 인터페이스)
  • URI으로 지정한 리소스에 대한 조작을 통일되고, 한정적인 인터페이스로 수행하는 아키텍처 스타일
  • HTTP 표준만 맞으면, 어떤 기술도 가능하다.
    • REST API 정의가 HTTP + JSON 이면, 어떤 언어에 종속되지 않고 모든 플랫폼에 사용 가능
• Stateless(무상태성)
  • 작업을 위한 상태정보를 저장하고 관리하지 않는다. 세션 정보나 쿠키 정보를 관리 X
  • Request만 Message로 처리하고, context 정보를 신경쓰지 않아도 되서 구현 단순
  • API 실행중 실패 발생시 Transaction 복구를 위해 기존의 상태를 저장할 필요가 있다.
  • API 서버는 들어오는 요청만 단순 처리 한다.
• Caching(캐시 가능)
  • REST는 HTTP(기존 웹표준)을 그대로 사용하기 때문에, HTTP가 가진 캐싱 기능 적용을 할 수 있다. 
• Code on demand
  • 서버는 고객에게 실제 실행 가능한 코드를 전송해줄 수 있다.
  • applet이나 스크립트 전송으로 클라이언트의 기능 확장이나 커스터마이즈 가능
• Hierarchical system(계층형 시스템)
  • 다층 계층으로 구성되어, 로드 밸런싱, 보안, 암호화 계층을 추가해 구조상의 유연성을 얻을 수 있다.
• Client-Server 구조
  • REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보)등을 직접 관리하는 구조
  • 각각의 역할이 확실하게 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로간의 의존성이 줄어들게 된다.

 

RESTful API 디자인

• 리소스와 행위를 명시적이고 직관적으로 분리
  • 리소스(URI)가 가리키는 것은 명사로 표현
  • 행위는 HTTP Method로 표현 - GET(조회), POST(생성), PUT(수정), PATCH(일부 수정), DELETE(삭제)
• Message는 Header와 Body를 명확하게 분리해서 사용
  • Entity는 Body에 담아 사용
  • 애플리케이션 서버가 행동할 판단의 근거가 되는 컨트롤 정보인 API 버전 정보, 응답받고자 하는 MIME 타입은 header에 담아 사용
    • MIME 유형 : Content-Type
  • header, body는 http header와 http body로 나눌 수 있다.
  • http body에 들어가는 json 구조 분리 가능
• API 버전 관리
  • 하위 호환성 보장
• 서버와 클라이언트가 같은 방식으로 사용해서 요청
  • 브라우저는 form-data 형식으로, 서버에서는 Json 형태로 보내지 않고 하나의 형태로 통일한다.
• URL에 케밥케이스(kebab-case) 사용

[GET] /userInfo
[GET] /user_Info

[GET] /user-Info

 

• Path Variable에 카멜케이스(camelCase) 사용

[GET] /user/{user_id}

[GET] /user/{userId}