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년에 그의 박사 학위 논문 "Architectural Styles and the Design of Network-based Software Architectures"에서 만들어냈습니다. REST라는 용어는 아직 초기 단계이지만 그 개념은 World Wide Web의 근간을 이루고 있습니다. 우리는 이 용어의 유래에 대한 역사를 깊이 다루지 않을 것입니다. 원본 소스를 자세히 알아보려면 Fielding의 논문을 살펴보세요 .

REST 제한사항 및 원칙

위에서 설명한 것처럼 REST는 분산 시스템의 구성 요소가 서로 상호 작용하는 방법을 정의합니다. 일반적으로 이는 요청-응답을 통해 발생합니다. 요청을 보내는 구성 요소를 클라이언트 라고 합니다 . 요청을 처리하고 클라이언트에 응답을 보내는 구성 요소를 서버 라고 합니다 . 요청과 응답은 대부분 HTTP(HyperText Transfer Protocol)를 통해 전송됩니다. 일반적으로 서버는 일종의 웹 애플리케이션입니다. 클라이언트는 아무것도 될 수 없지만 꽤 많을 수 있습니다. 예를 들어 서버에서 데이터를 요청하는 모바일 애플리케이션이 있습니다. 또는 데이터를 다운로드하기 위해 웹 페이지에서 서버로 요청을 보내는 브라우저입니다. 애플리케이션 A는 애플리케이션 B로부터 데이터를 요청할 수 있습니다. 그러면 A는 B와 관련된 클라이언트이고, B는 A와 관련된 서버입니다. 동시에 A는 C, D, D 등의 요청을 처리할 수 있습니다. 이 경우 애플리케이션 A는 서버이자 클라이언트입니다. 그것은 모두 상황에 따라 다릅니다. 한 가지는 분명합니다. 요청을 보내는 구성 요소는 클라이언트입니다. 요청을 수신, 처리 및 응답하는 구성 요소는 서버입니다. 그러나 구성요소가 요청-응답을 통해 통신하는 모든 시스템이 REST(또는 RESTful) 시스템은 아닙니다. 시스템이 RESTful로 간주되려면 다음과 같은 6가지 REST 제약 조건을 "적합"해야 합니다.

1. 아키텍처를 클라이언트-서버 모델로 가져오기

이러한 제한의 기본은 요구 사항의 차별화입니다. 클라이언트 인터페이스의 요구 사항과 데이터를 저장하는 서버의 요구 사항을 분리해야 합니다. 이러한 제한으로 인해 클라이언트 코드의 다른 플랫폼으로의 이식성이 향상되고, 서버 부분이 단순화되어 시스템 확장성이 향상됩니다. "클라이언트"와 "서버"의 차이로 인해 서로 독립적으로 개발할 수 있습니다.

2. 상태 부족

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

3. 캐싱

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

4. 인터페이스의 통일성

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

5. 레이어

레이어는 네트워크의 계층 구조를 나타냅니다. 때로는 클라이언트가 서버와 직접 통신할 수도 있고 때로는 중간 노드와 간단히 통신할 수도 있습니다. 중간 서버를 사용하면 로드 밸런싱 및 분산 캐싱을 통해 확장성을 높일 수 있습니다. 예를 들어 보겠습니다. 전 세계적으로 인기를 끌고 있는 모바일 애플리케이션을 상상해 봅시다. 그 핵심 부분은 이미지를 로딩하는 것입니다. 수백만 명의 사용자가 있기 때문에 하나의 서버가 이러한 과도한 부하를 견딜 수 없습니다. 시스템을 여러 계층으로 나누면 이 문제가 해결됩니다. 클라이언트는 중간 노드에 이미지를 요청하고, 중간 노드는 현재 로드가 가장 적은 서버에 이미지를 요청한 후 해당 이미지를 클라이언트에 반환합니다. 계층 구조의 각 수준에서 캐싱이 올바르게 적용되면 우수한 시스템 확장성을 얻을 수 있습니다.

6. 주문형 코드(선택적 제한)

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

REST의 이점

위의 모든 제한 사항을 준수하는 애플리케이션에는 다음과 같은 장점이 있습니다. 안정성(손실될 수 있는 클라이언트 상태 정보를 저장할 필요가 없음)

• 성능(캐시 사용으로 인해)
• 확장성;
• 상호작용 시스템의 투명성;
• 인터페이스의 단순성;
• 구성 요소의 이식성;
• 변경의 용이성;
• 새로운 요구 사항에 적응하고 발전하는 능력.

2부: 클라이언트와 서버 간 통신 3부: Spring Boot에서 RESTful 서비스 생성