REST 개요. 파트 1: REST란 무엇입니까?

안녕! 오늘 우리는 매우 흥미롭고 가장 중요한 노동 시장에서 수요가 많은 주제인 REST에 대해 배울 것입니다. REST에 대한 개요를 세 부분으로 나눌 것입니다.

1. 첫 번째 부분에서는 REST의 역사를 다루고 REST의 기반이 되는 원칙을 설명합니다.

2. 두 번째에서는 클라이언트와 서버 간의 통신이 HTTP 프로토콜을 통해 발생하는 방식을 고려할 것입니다.

3. 세 번째에서는 "Postman"이라는 프로그램을 사용하여 테스트할 작은 RESTful 애플리케이션을 작성합니다.

이 문서는 다음 용어에 익숙한 독자를 대상으로 합니다.

• HTTP
• URL 및 URI
• JSON 및 (약간의) XML
• 의존성 주입

파트 1. REST란 무엇입니까?

IT 세계에서와 마찬가지로 REST는 약어입니다. "REpresentational State Transfer" 에서 파생됩니다 . 이것은 컴퓨터 네트워크에서 분산 시스템의 구성 요소 간의 상호 작용을 위한 아키텍처 스타일입니다. 간단히 말해 REST는 서로 다른 위치에 물리적으로 위치할 수 있는 시스템의 서로 다른 구성 요소 간의 상호 작용(데이터 교환) 스타일을 결정합니다. 이 아키텍처 스타일은 분산 시스템을 설계할 때 준수해야 하는 일관된 제약 조건 집합입니다. 이러한 제약 조건을 REST의 기본 원칙이라고도 합니다. 많지 않고 6 개뿐입니다. 나중에 이야기하겠습니다.

REST의 역사

REST라는 용어는 HTTP 프로토콜의 창시자 중 한 명인 Roy Fielding이 그의 박사 학위에서 소개했습니다. 2000년 "아키텍처 스타일 및 네트워크 기반 소프트웨어 아키텍처 설계"라는 제목의 논문. REST라는 용어는 아직 젊다고 할 수 있지만 그것이 나타내는 개념은 월드 와이드 웹의 핵심에 있습니다. 우리는 용어의 역사에 대해 깊이 파고들지 않을 것입니다. 주요 소스에 대해 알아보려면 Fielding의 논문을 살펴보십시오 .

REST 제약 조건 및 원칙

위에서 설명한 것처럼 REST는 분산 시스템의 구성 요소가 서로 상호 작용하는 방법을 정의합니다. 일반적으로 이것은 요청-응답 프로세스를 통해 발생합니다. 요청을 보내는 구성 요소를 클라이언트라고 하고 요청 을 처리하고 클라이언트에 응답을 보내는 구성 요소를 서버라고 합니다 .. 요청 및 응답은 대부분 HTTP 프로토콜을 통해 전송됩니다. HTTP는 HyperText Transfer Protocol의 약자입니다. 일반적으로 서버는 일부 웹 응용 프로그램입니다. 클라이언트는 거의 모든 것이 될 수 있습니다. 예를 들어 서버에서 데이터를 요청하는 모바일 앱입니다. 또는 데이터를 다운로드하기 위해 웹 페이지에서 서버로 요청을 보내는 브라우저입니다. Application A는 Application B에게 데이터를 요청할 수 있습니다. 이 경우 A는 B에 대한 클라이언트이고 B는 A에 대한 서버입니다. 동시에 A는 B, C, D 등의 요청을 처리할 수 있습니다. 이 경우 애플리케이션 A는 서버이자 클라이언트입니다. 모든 것은 상황에 따라 다릅니다. 한 가지는 확실합니다. 요청을 보내는 구성 요소는 클라이언트입니다. 요청을 수신, 처리 및 응답하는 구성 요소가 서버입니다. 하지만, 구성 요소가 요청-응답 프로세스를 통해 통신하는 모든 시스템이 RESTful 시스템인 것은 아닙니다. 시스템이 RESTful로 간주되려면 6개의 REST 제약 조건을 준수해야 합니다.

1. 클라이언트-서버 아키텍처

이 제약 조건은 관심사의 분리에 관한 것입니다. 클라이언트 인터페이스의 요구 사항과 데이터를 저장하는 서버의 요구 사항을 구분할 필요가 있습니다. 이 제약 조건은 클라이언트 코드를 다른 플랫폼에 더 쉽게 이식할 수 있도록 하며 서버 측을 단순화하면 시스템의 확장성이 향상됩니다. "클라이언트"와 "서버"를 구분하면 서로 독립적으로 개발할 수 있습니다.

2. 무국적자

RESTful 아키텍처는 다음 조건을 충족해야 합니다. 요청 사이의 기간 동안 서버는 클라이언트의 상태에 대한 정보를 저장해서는 안 되며 그 반대의 경우도 마찬가지입니다. 클라이언트의 모든 요청은 요청을 완료하는 데 필요한 모든 정보를 서버에 제공하는 방식으로 구성되어야 합니다. 따라서 서버와 클라이언트 모두 이전 메시지에 의존하지 않고 수신된 메시지를 "이해"할 수 있습니다.

3. 캐시 가능

클라이언트는 서버 응답을 캐시할 수 있습니다. 클라이언트가 후속 요청에 대한 응답으로 오래되거나 잘못된 데이터를 수신하지 않도록 명시적으로 또는 암시적으로 캐시됨 또는 캐시되지 않음으로 지정되어야 합니다. 올바른 캐싱은 일부 클라이언트-서버 상호 작용을 완전히 또는 부분적으로 제거하여 시스템 성능과 확장성을 더욱 향상시킵니다.

4. 통일된 인터페이스

RESTful 아키텍처의 기본 요구 사항에는 통일되고 균일한 인터페이스가 포함됩니다. 클라이언트는 요청을 보낼 때 사용해야 하는 형식과 주소를 항상 이해해야 하며, 서버도 클라이언트 요청에 응답할 때 사용해야 하는 형식을 이해해야 합니다. 무엇을, 어디서, 어떤 형식으로, 어떻게 데이터를 보낼 것인지를 설명하는 이 일관된 클라이언트-서버 상호 작용이 통합 인터페이스입니다.

5. 레이어

계층이란 네트워크의 계층적 구조를 의미합니다. 때로는 클라이언트가 서버와 직접 통신할 수 있고 때로는 중간 노드와만 통신할 수도 있습니다. 중간 서버를 사용하면 로드 밸런싱 및 분산 캐싱 덕분에 확장성을 높일 수 있습니다. 예를 들어 보겠습니다. 전 세계적으로 인기 있는 모바일 앱을 상상해 보세요. 앱의 필수적인 부분은 사진을 로드하는 것입니다. 사용자가 수백만 명에 달하므로 단일 서버가 이러한 무거운 로드를 처리할 수 없습니다. 시스템을 계층으로 분리하면 이 문제가 해결됩니다. 클라이언트가 중간 노드에 사진을 요청하면 중간 노드는 현재 부하가 가장 적은 서버에 사진을 요청하고 클라이언트에게 사진을 반환한다. 계층 구조의 각 수준에서 캐싱이 올바르게 적용되면

6. 주문형 코드(선택 사항)

이 제약 조건은 클라이언트가 애플릿이나 스크립트의 형태로 서버에서 코드를 다운로드하여 기능을 확장할 수 있음을 의미합니다.

RESTful 아키텍처의 장점

앞서 언급한 모든 제약 조건을 준수하는 애플리케이션은 다음과 같은 이점이 있습니다. 안정성(손실될 수 있는 클라이언트 상태를 저장할 필요가 없음)

• 성능(캐시 사용으로 인한)
• 확장성
• 투명한 커뮤니케이션
• 간단한 인터페이스
• 휴대성
• 쉽게 변경하는 능력
• 새로운 요구 사항에 맞게 진화하고 적응하는 능력

REST 개요. 2부: 클라이언트와 서버 간의 통신 REST 개요. 3부: Spring Boot에서 RESTful 서비스 구축