[ Web ] 5. REST API

REST (REpresentational State Transfer) 기본

REST : 웹(HTTP)의 장점을 활용한 아키텍처

 

Method	의미	Idempotent
POST	Create	NO
GET	READ	Yes
PUT	Update	Yes
DELETE	Delete	Yes
PATCH	Partial Update	NO

※ Idempotent : 한 번 수행하나, 여러 번 수행하나 결과가 같은 것

 

Resource

• URI
• 모든 것을 Resource(명사)로 표현하고, 세부 Resource에는 id를 붙임
• 행위를 나타내는 동사는 URI에 포함하지 않음

 

Message

• 메시지 포맷이 존재 ( JSON, XML )

 

Resource 지향 아키텍처(ROA : Resource Oriented Architecture)

• Resouce 기반의 복수형 명사 형태의 정의를 권장

 

REST 특징

1. Client-Server: 클라이언트와 서버 역할을 분리
2. Stateless: 각 요청은 독립적으로 처리 (서버는 상태 저장 X)
3. Cacheable: HTTP 캐시 기능을 활용
4. Uniform Interface: 일관된 인터페이스로 자원 접근
5. Layered System: 중간 계층(프록시, 로드밸런서 등)을 둘 수 있음
6. Code on Demand (Optional): 클라이언트에 코드(JavaScript 등)를 전송해 실행 가능

 

Uniform Interface

• HTTP 표준만 맞는다면, 어떤 기술도 가능한 interface 스타일
• REST API 정의를 HTTP + JSON으로 했다면 C, Java, 등 특정 언어나 기술에 종속 받지 않고, 모든 플랫폼에 사용이 가능한 Loosely Coupling 구조

 

• Self-Descriptive Messages
  • API 메시지만 보고, API를 이해할 수 있어야 함
  • Resource, Method를 이용해 무슨 행위를 하는지 직관적으로 이해할 수 있음
• HATEOAS(Hypermedia As The Engine Of Application State)
  • Application의 상태(State)는 Hyperlink를 통해 전이 되어야 함
  • 서버는 현재 이용 가능한 다른 작업에 대한 하이퍼링크를 포함하여 응답해야 함
  • 복잡성 증가로 REST API에서는 잘 사용하지 않음
• Resource Identification In Requests
  • 모든 리소스는 고유한 URI로 식별 되어야 함
  • users/7 과 같이 URI는 리소스를 명확히 식별함
• Resource Manipulation Through Representations
  • 클라이언트는 리소스를 직접 조작하지 않고 표현(representation)을 통해 리소스를 변경함
  • 표현은 JSON, XML 등
  • 서버는 해당 표현을 기반으로 내부 리소스 조작

 

Statelessness

• HTTP Session과 같은 컨텍스트 저장소에 상태 정보 저장 안 함
• Request만 Message로 처리하면 되고, 컨텍스트 정보를 신경쓰지 않아도 되므로, 구현이 단순해짐
• REST API 실행 중 실패가 발생한 경우, Transaction 복구를 위해 기존의 상태를 저장할 필요가 있음(POST method를 제외)