[Spring] REST, REST API

최근 다양한 브라우저, 모바일 디바이스 등 다양한 클라이언트가 등장했다

→ 서버 프로그램은 다양한 클라이언트와 통신할 수 있어야 한다.

→ 멀티 플랫폼 지원을 위해 REST 등장

 

REST

• 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 방식
• HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 아키텍처자원의 표현 (representation) 그 자원을 표현하기 위한 이름 ex) “students”
• 자원 해당 소프트웨어가 관리하는 모든 것 ex) 문서, 그림, 데이터, 소프트웨어 자체 등

장점

• • HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
• REST API 메시지가 의도하는 바를 명확하게 나타내기 때문에 의도하는 바를 쉽게 파악할 수 있다.
• 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.
• 서버와 클라이언트의 역할을 명확하게 분리한다.

단점

• 표준이 존재하지 않는다.
• HTTP method 가 제한적이다.

 

구성 요소

• 자원
  • 모든 자원은 고유한 ID를 가진다. (자원은 서버에 존재)
  • ID = HTTP URI (ex) /groups/:group_id )
  • 클라이언트는 URI를 이용해서 자원을 지정하고, 해당 자원의 상태에 대한 조작을 서버에 요청한다.
• 행위 (Verb)
  • HTTP 프로토콜의 method를 사용
  • GET, POST, PUT, DELETE
• 표현 (Representation of Resource)
  • 클라이언트가 자원의 상태에 대한 조작을 요청 > 서버는 요청에 대한 적절한 응답을 보냄
  • REST에서 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 표현될 수 있다.

 

REST 6가지 원칙

1. Server-Client 구조
2. Stateless
3. Cacheable
4. Layered System
5. Code-On-Demand (optional)
6. Uniform Interface

1️⃣ Server-Client 구조

클라이언트와 서버는 각각의 역할과 책임을 갖는다.

• 서버: API를 제공하고 비즈니스 로직 처리 및 데이터 저장을 담당
• 클라이언트: 사용자 인터페이스와 사용자 요청을 처리
• 장점
  • 서로 역할을 분리 > 서로 간 의존성을 줄인다, 시스템의 유연성과 확장성 증가

2️⃣ Stateless

HTTP 프로토콜은 statless 프로토콜로 REST도 무상태성을 가진다. 서버는 클라이언트의 컨텍스트(상태, 세션 정보)를 저장하지 않는다.

• 들어오는 각 요청을 완전히 별개의 것으로 인식하고 처리한다. > 이전 요청이 다음 요청의 처리에 연관되어서는 안된다.
• 서버의 처리 방식에 일관성을 부여 > 서비스의 자유도 증가

3️⃣ Cacheable (캐시 처리 가능)

REST는 웹 표준 프로토콜을 그대로 사용함으로 웹에서 사용하는 기존 인프라를 그대로 사용할 수 있다. 즉, HTTP의 캐싱 기능을 사용할 수 있다.

• 서버는 변경되지 않은 리소스에 대해서 실제 데이터 전송 없이 304 Not Modified 응답을 반환할 수 있음 > 해당 응답을 받으면 클라이언트는 캐시에서 직접 리소스를 가져온다
• 대량의 요청을 효율적으로 처리 가능
• 캐시 사용 > REST Server 트랜잭션을 줄임 > 전체 응답시간 단축, 성능 향상, 네트워크 부하 감소

4️⃣ Laysed System (계층화 시스템)

클라이언트는 REST API 만 호출하고, REST 서버는 다중 계층으로 구성될 수 있다.

• API 서버는 순수 비즈니스 로직을 수행하고, 그 앞 단에 보안, 로드 밸런싱, 암호화, 사용자 인증 등을 추가할 수 있다.
• 각 계층은 독립적으로 변경이 가능 > 구조의 유연성 제공
• 확장성, 보안성 향상

5️⃣ Code on Demand (Optional)

클라이언트는 서버로부터 실행 가능한 코드를 받아서 실행할 수 있다.

• 클라이언트는 서버로부터 받은 코드를 활용해 동적인 기능을 추가할 수 있다 > 클라이언트의 유연성
• 주의할 점
  • 보안 이슈: 클라이언트 쪽에서 악의적으로 코드를 변조해서 실행할 수 있다.
  • 클라이언트 의존성: 클라이언트가 서버로부터 받은 코드에 의존하게 된다. 서버 변경 시 클라이언트도 함께 수정해야 할 수 있음.

6️⃣ Uniform Interface (인터페이스 일관성)

리소스에 대한 조작을 수행하는 인터페이스를 일관성 있게 설계해야 한다.

(인터페이스가 아래 조건을 만족해야 한다는 의미)

1. 리소스가 고유한 URL로 식별돼야 한다.
2. 리소스를 입력/수정/삭제할 때 HTTP 메세지 표현(상태)를 담아서 전송한다.
3. Self-descriptive Message
   • 각 요청과 응답은 자체적으로 해석하기에 충분한 메타 데이터를 포함해야 한다.
   • 메타 데이터: Content-Type, 문자 인코딩 형식, 인증 방법 등
4. • 응용 프로그램 상태의 엔진으로써 하이퍼미디어
   • 서버는 클라이언트에게 애플리케이션 상태 정보를 전달하기 위해 하이퍼미디어 링크를 포함한 응답을 제공한다.
   • HTTP 응답 메시지를 전달할 때 관련 리소스 링크 정보나 다음에 수행할 수 있는 작업의 링크 정보를 포함하여 리턴하는 것
   • 클라이언트는 해당 링크를 따라 자원을 검색하고 상호작용 할 수 있다.HATEOS (Hypermedia as the Engine of Application State)

{
	// 책에 대한 정보
	"id": 123,
	"title": "The Great Gatsby",
	"author": "F, Scott Fitzgerald",
	"links" [
		{
			"rel": "self",
			"href": "/books/123"
		},
		{
			"rel": "author",
			"href": "/authors/456" // 작가에 대한 정보 API
		},
		{
			"rel": "reviews",
			"href": "/books/123/reviews" // 리뷰에 대한 정보 API
		}
	]
}

 

URI 와 URL의 차이점?

URL은 Uniform Resource Locator로 인터넷 상 자원의 위치를 의미합니다.

반면, URI는 Uniform Resource Identifier로 인터넷 상의 자원을 식별하기 위한 문자열의 구성이다. URI는 URL을 포함하게 된다.