REST(REpresentational State Transfer) 기본

REST의 요소

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

Method

Idempotent(멱등성):같은 요청을 여러 번 보내더라도 결과가 같다면 그 메서드는 멱등하다

즉, 요청을 1번 보내든 100번 보내든, 서버의 상태가 변하지 않으면 멱등한 메서드이다.

멱등성은 어떻게 활용될 수 있나요? 🤔

모종의 이유로 전송 커넥션이 끊어졌을 때, 멱등성은 클라이언트가 다시 같은 요청을 해도 되는가에 대한 판단 근거가 될 수 있습니다. 멱등하다면 요청을 재시도할 때 같은 서버의 상태를 보장하기 때문에 문제가 없습니다.

반면, 멱등하지 않다면 재시도 요청시 중복 요청을 보내 문제를 발생 시킬 수 있습니다. 예를 들어, 사용자가 결제하는 시점에 타임아웃으로 인해 정상 응답을 못받는 상황을 생각해 볼 수 있습니다. 해당 경우에서 멱등하지 않은 결제 API 경우에는 결제가 성공했는지 수동으로 확인하고 재요청해야합니다. 반면, 멱등한 결제 API의 경우에는 안심하고 여러 번 요청할 수 있으며 중복 요청으로 발생하는 문제(중복 결제)를 방지할 수 있습니다.

Resource

• http://myweb/users와 같은 URI
• 모든 것을 Resource로 표현하고, 세부 Resource에는 id를 붙인다.

Message

메세지 포맷이 존재: JSON,XML과 같은 형태가 있음

HTTP POST, http://myweb/users/
{
	"users" : {
		"name" : "hsh"
	}
}

REST 특징

1. Uniform Interface

👉 개념 요약

서로 다른 시스템끼리 통신할 때, “하나의 방식(일관된 인터페이스)”만 따르면 문제없이 작동하도록 한다는 원칙입니다.

REST에서는 HTTP 프로토콜 + URI(자원 경로) + 표준 메서드(GET, POST, PUT 등) + 표준 포맷(JSON, XML 등) 만 맞추면 클라이언트가 어떤 기술이든 상관없이 서버랑 통신할 수 있다.

EX) REST API 정의를 HTTP + JSON로 하였다면, C,Java,Python,IOS 플랫폼 등 특정 언어나 기술에 종속 받지 않고, 모든 플랫폼에 사용이 가능한 Lossley Coupling(느슨한 결합)구조

📎 포함되는 요소들

• Self-Descriptive Messages → 메시지만 보고도 어떤 행위를 하는지 직관적으로 알 수 있음 (예: GET /users/1)
• HATEOAS (Hypermedia As The Engine Of Application State) → 클라이언트가 다음에 취할 수 있는 상태를 서버가 하이퍼링크로 제공 → 응답에 "links": [ { "rel": "next", "href": "/orders/2" } ] 같은 형태로 제공됨
• Resource Identification in Requests → 리소스는 URI로 명확히 식별되어야 함 (ex. /users/1)
• Resource Manipulation Through Representations → 리소스는 JSON, XML 등으로 표현되며, 이를 통해 수정 가능

2. Statelessness

• 서버는 클라이언트의 상태를 저장하지 않음 (세션, 컨텍스트 없음)
• 클라이언트는 요청 시 모든 필요한 정보를 포함해야 함
• 구현이 단순해지고, 확장성(Scalability) 향상

📌 예외: 일부 상태 정보를 유지할 필요가 있는 POST 요청에서는, 트랜잭션 복구를 위한 처리 필요

3. Resource-Oriented Architecture (ROA)

• 리소스 중심 설계 원칙
• URI는 자원을 명사 형태(복수형)로 표현 (예: /users, /products/1)
• 행위는 HTTP Method로 구분 (GET, POST, PUT, DELETE 등)

4. Client-Server Architecture

클라이언트와 서버는 명확히 역할이 분리됨

클라이언트: 사용자 인터페이스, 사용자 경험 처리

서버: 데이터 처리, 저장, 비즈니스 로직

이 구조는 독립적인 개발과 배포 가능

5. Cacheability

• HTTP의 캐시 기능을 활용해 응답 데이터를 클라이언트나 중간 서버가 재사용 가능
• 서버는 응답에 Cache-Control 같은 헤더를 포함하여 캐시 여부를 제어
• 성능 향상 + 트래픽 절감

6. Layered System

• 클라이언트는 중간 서버(프록시, 게이트웨이, 로드밸런서 등)를 통해 요청 가능
• 각 계층은 독립적으로 확장 가능하며, 보안, 로드 분산, 캐시 등을 담당할 수 있음

7. Code on Demand

• 서버가 클라이언트에게 코드(JavaScript 등)를 전달하여 실행하게 할 수 있음
• 사용성 확장 가능하지만, 제한적으로 사용됨 (REST에서 필수는 아님)

📌 정리 요약표