REST(Representational State Transfer) 정의, REST API / RESTful API 특징

REST (Representational State Transfer) 정의

웹 서비스를 설계하고 구현하기 위한 아키텍처 스타일로 HTTP 프로토콜과 리소스 지향적인 구조를 기반으로 클라이언트와 서버 간의 통신을 단순화하고 효율적으로 처리할 수 있도록 함.

 

✅ 리소스

: 웹 서비스에서 클라이언트가 요청하고 서버가 제공하는 데이터 또는 객체를 말하며, 고유한 식별자(URI)를 가지고 있다.

 

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

 

✅ URI

: 인터넷상에서 고유한 리소스를 식별하기 위한 문자열로 URL(Uniform Resource Locator)과 URN(Unifrom Resource Name)의 상위 개념이다.

 

✅ HTTP Method

: 클라이언트가 서버에 요청을 보낼 때 어떤 동작을 수행할지를 나타내는 방법으로 일반적으로 사용되는 메서드는 5가지가 존재한다.

 

1. GET: 서버로부터 리소스를 가져오기 위해 사용된다. 주로 데이터의 조회나 검색에 사용되며, 요청한 리소스의 데이터를 읽어온다. - Read
2. POST: 서버에 새로운 데이터를 생성하기 위해 사용된다. 주로 데이터의 생성이나 업로드에 사용되며, 요청 본문에 데이터를 담아 서버로 전송한다. - Create
3. PUT: 서버의 리소스를 업데이트 또는 생성하기 위해 사용된다. 주로 특정 리소스를 대체하거나 새로운 리소스를 생성하며, 요청 본문에 데이터를 담아 서버로 전송한다. - Update
4. DELETE: 서버의 리소스를 삭제하기 위해 사용된다. 주로 특정 리소스를 삭제하며, 요청한 리소스를 서버에서 제거한다. - Delete
5. PATCH: 서버의 리소스를 부분적으로 수정하기 위해 사용된다. 주로 특정 리소스의 일부를 업데이트하며, 요청 본문에 수정할 데이터를 담아 서버로 전송한다. - Update

 

REST 구성요소

1. 자원 (Resource) - URI

: 모든 자원에 고유한 ID가 존재하고, 이 자원은 서버에 존재한다. 

 

2. 행위 (Verb) - HTTP Method

: HTTP 프로토콜의 Method를 사용하고, GET, POST, PUT, DELETE와 같은 메서드를 제공한다.

 

3. 표현 (Representation of Resource)

: 클라이언트가 자원의 상태에 대한 조작을 요청하면 서버는 이에 적절한 응답을 보낸다. 주로 JSON 혹은 XML를 통해 데이터를 주고받는다.

 

 

REST 장단점

장점

• 간결하고 단순한 인터페이스: 개발자들이 REST 웹 서비스를 쉽게 이해하고 사용할 수 있음.
• 분리된 클라이언트와 서버: 서버와 클라이언트가 독립적으로 진화하고 변경될 수 있으며, 확장성과 유지 보수성을 제공.
• 자유로운 데이터 형식: 일반적으로 JSON, XML 형식으로 데이터를 전송할 수 있음. 이는 다양한 클라이언트와 서버 간의 상호 운용성을 보장하고, 개발자들이 자유롭게 데이터를 구조화하고 교환할 수 있음.
• 캐시 지원: HTTP 프로토콜을 기반으로 하기 때문에 캐싱 메커니즘을 활용할 수 있음. 서버의 응답을 클라이언트가 캐시 하여 불필요한 네트워크 요청을 줄일 수 있으므로 성능 향상에 도움을 줌.

 

단점

• 유연성 부족: 일정한 원칙과 제약을 가지고 있기 때문에 어떤 경우에는 유연성이 부족할 수 있다. 특히, 복잡한 도메인 모델이나 비즈니스 로직을 표현하기에는 제한적일 수 있음.
• 상태의 관리: REST는 상태를 관리하지 않은 상태 없는 아키텍처 스타일이다. 이는 클라이언트가 각각의 요청에서 필요한 상태 정보를 모두 제공해야 한다는 의미를 가진다. 
• 세밀한 제어의 어려움: 일반적으로 CRUD(Create, Read, Update, Delete) 작업을 위한 메서드를 제공하지만 더 세밀한 작업이 필요한 경우에는 제어가 어려울 수 있다.

 

REST 특징

1. Server-Client (서버-클라이언트) 구조

: 자원이 있는 쪽이 서버, 자원을 요청하는 쪽이 클라이언트가 된다. 서버는 API를 제공하고 비즈니스 로직 처리 및 저장을 책임진다. 각각의 역할이 명확히 정의되어 시스템의 확장성과 유연성을 향상시킨다.

 

2. Stateless (무상태성)

: 서버와 클라이언트 간의 통신에서 상태를 관리하지 않는다. 각 요청은 독립적이며, 서버는 클라이언트의 이전 상태를 유지하지 않는다. 이는 서버의 확장성과 클라이언트의 세션 관리 부담을 줄여준다.

 

3. Cacheable (캐시 처리 가능)

: 캐시는 서버의 응답을 클라이언트가 저장하여 동일한 요청에 대한 응답을 반복해서 받지  않도록 한다. 이는 네트워크 대역폭을 절약하고 응답 시간을 줄이는 데 도움이 된다.

 

4. Layered System (계층화)

: 서버는 중간 계층 서버를 통해 요청을 전달할 수 있다. 이는 시스템의 확장성과 유연성을 높이고, 보안, 로드 밸런싱, 캐싱 등을 구현하는데 유용하다.

 

5. Code-On-Demand

: 서버로부터 스크립트를 받아서 클라이언트에 실행한다. 이 특징은 반드시 충족할 필요는 없다.

 

6. Unform Interface (인터페이스 일관성)

: URI로 지정한 자원에 대한 조작을 통일되고 한정적인 인터페이스를 수행한다. HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용 가능하다. 특정 언어나 기술에 종속되지 않는다.

 

 

REST API 정의

REST 기반으로 서비스 API를 구현한 것

 

✅ API (Application Programming Interface) 

: 데이터와 기능의 집합을 제공하여 컴퓨터 프로그램 간 상호작용을 촉진하며, 서로 정보를 교환가능 하도록 하는 것

 

✅ REST API 설계 규칙

1. 명사형으로 리소스 표현한다.

: 일반적으로 동사형이 아닌 명사형으로 표현되어야 한다. ex) /users

 

2. 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용한다.

: ex) http://restapi.example.com/houses/home 

 

3. URI 마지막 문자로 슬래시 구분자(/)를 포함하지 않는다.

: 분명한 URI를 만들어 통신을 해야 하기 때문에 혼동을 주지 않도록 URI 경로의 마지막에는 슬래시(/)를 사용하지 않는다.

 

4. 밑줄(_)은 URI에 사용하지 않고, 하이픈(-)으로 가독성을 높인다.

5. URI 경로에는 소문자가 적합하다.

6. 자원에 대한 행위는 HTTP Method(GET, POST 등)로 표현하며, URI에 들어가면 안 된다.

7. 파일확장자는 URI에 포함하지 않는다.

: ex) http://restapi.example.com/review/img.jpg (x)

 

✅ 응답 코드 (2xx: 성공 / 4xx: 클라이언트 실패 / 5xx: 서버 실패)

• 200: 클라이언트 요청 정상수행 (응답에 대한 메시지가 포함)
• 201: 리소스 생성 요청에 대한 정상 처리
• 202: 리소스 생성 요청이 비동기적으로 처리될 때 사용
• 204: 클라이언트 요청 정상수행 (응답에 대한 메시지 미포함, 삭제 요청 따위에 사용)
• 400: 클라이언트 요청이 부적절할 때 사용 (부적절한 이유를 응답 body에 넣어줘야 함)
• 401: 클라이언트가 인증되지 않은 상태에서 보호된 리소스를 요청할 때 사용
• 403: 클라이언트가 인증상태와 무관하게 응답하고 싶지 않은 리소스를 요청할 때 사용 (400 사용을 권장)
• 404: 클라이언트가 요청한 리소스가 존재하지 않을 때 사용
• 405: 클라이언트가 불가능한 메소드를 사용했을  때 사용

 

 

RESTful 정의

일반적으로 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어로 'REST API'를 제공하는 웹 서비스를 'RESTful'하다고 할 수 있다.