REST 개요. 2부: 클라이언트와 서버 간의 통신

1부: REST란 무엇입니까? 이 부분에서는 클라이언트와 서버 간에 통신이 어떻게 이루어지는지 자세히 살펴보겠습니다. 그 과정에서 우리는 새로운 용어를 공개하고 이에 대한 설명을 제공할 것입니다. 모든 것을 명확하게 하기 위해 일부 RESTful 애플리케이션의 예를 사용하여 클라이언트-서버 통신을 분석하겠습니다. 고객과 고객의 주문에 대한 정보를 저장할 수 있는 웹 애플리케이션을 개발한다고 가정해 보겠습니다. 저것들. 우리 시스템은 일부 엔터티를 조작할 수 있습니다. 즉, 생성, 편집, 삭제 및 이에 대한 정보 제공이 가능합니다. 이러한 엔터티는 다음과 같습니다.

• 클라이언트 - 클라이언트;
• 주문 - 고객 주문;
• 품목-상품.

REST 아키텍처에서 클라이언트는 데이터를 얻거나 수정하기 위해 서버에 요청을 보내고, 서버는 클라이언트의 요청에 대한 응답을 보냅니다.

요청사항

클라이언트 요청은 거의 항상 HTTP를 통해 이루어집니다. 일반적으로 HTTP 요청은 여러 구성 요소로 구성됩니다.

• HTTP 방식;
• 제목;
• URI;
• 요청 본문.

아래에서는 각 구성요소 부분에 대해 좀 더 자세히 살펴보겠습니다.

URI 및 리소스

클라이언트가 요청을 통해 얻거나 수정하는 데이터를 리소스라고 합니다. 클라이언트-서버 상호 작용의 기본은 리소스 조작입니다. REST의 리소스는 이름을 지정할 수 있는 모든 것입니다. 어떤 의미에서 이는 Java의 클래스와 같습니다. Java에서는 무엇이든 클래스를 만들 수 있습니다. REST에서도 마찬가지입니다. 리소스는 사용자, 문서, 보고서, 주문 등 무엇이든 될 수 있습니다. 이 모든 것은 일부 엔터티의 추상화일 수도 있고 그림, 비디오, 애니메이션, PDF 파일과 같은 파일과 같은 구체적인 것일 수도 있습니다. 이 예에는 다음과 같은 3가지 리소스가 있습니다.

• 클라이언트 - 클라이언트;
• 주문 - 고객 주문;
• 품목-상품.

클라이언트는 소위 엔드포인트 또는 엔드포인트에 요청을 보냅니다. 간단히 말해서 엔드포인트 는 네트워크의 주소와 같습니다. 더 깊이 들어가 보면 엔드포인트는 추상 또는 물리적 리소스를 식별하는 일련의 문자 인 URI 입니다. 통일 자원 식별자(Uniform Resource Identifier) ​​- 통합 자원 식별자. 엔드포인트 또는 URI를 경로(리소스에 대한 경로)라고 부르는 경우도 있습니다. 이 기사에서는 URI라는 용어를 사용합니다. 각 특정 리소스에는 고유한 URI가 있어야 합니다. 각 리소스가 항상 고유한 URI를 갖도록 하는 책임은 서버 개발자의 어깨에 있습니다. 이 예에서 우리는 개발자이므로 우리가 알고 있는 방식으로 수행하겠습니다. 관계형 데이터베이스에서 기본 키를 특정 숫자 ID로 설정하는 것이 관례인 경우가 많으며, REST에서는 각 리소스에 고유한 ID가 있습니다. REST의 리소스 ID가 해당 리소스에 대한 정보가 저장된 데이터베이스의 레코드 ID와 일치하는 경우가 종종 있습니다. REST URI는 일반적으로 일부 리소스를 설명하는 복수형 명사로 시작됩니다. 예를 들어 클라이언트라는 단어에서. 다음으로 특정 클라이언트의 식별자인 슬래시를 통해 ID가 표시됩니다. 예:

• /clients - 모든 기존 클라이언트의 URI입니다.
• /clients/23 - 특정 클라이언트의 URI, 즉 ID=23인 클라이언트입니다.
• /clients/4 - 특정 클라이언트의 URI, 즉 ID=4인 클라이언트입니다.

하지만 그게 전부는 아닙니다. 주문을 추가하여 URI를 확장할 수 있습니다.

• /clients/4/orders — 클라이언트 번호 4의 모든 주문에 대한 URI;
• /clients/1/orders/12 - 클라이언트 번호 1의 주문 번호 12의 URI입니다.

이 체인을 계속해서 상품을 추가하면 다음을 얻습니다.

• /clients/1/orders/12/items — 클라이언트 1번이 주문한 12번의 모든 제품 목록의 URI입니다.

중첩 수준에서 핵심은 URI를 직관적으로 만드는 것입니다.

HTTP 방식

HTTP 방법(영어 HTTP 방법)은 리소스에 대한 주요 작업을 나타내는 컨트롤 및 구분 기호를 제외한 모든 문자의 시퀀스입니다. 몇 가지 일반적인 HTTP 메서드가 있습니다. RESTful 서비스에서 가장 자주 사용되는 항목을 나열합니다.

• GET - 특정 리소스(ID를 통해) 또는 리소스 모음에 대한 정보를 얻는 데 사용됩니다.
• POST - 새 리소스를 만드는 데 사용됩니다.
• PUT - 리소스를 변경하는 데 사용됩니다(ID를 통해).
• DELETE - 리소스를 삭제하는 데 사용됩니다(ID를 통해).

제목

요청과 응답에는 HTTP 헤더가 포함됩니다. 요청(또는 응답)에 대한 추가 정보를 보냅니다. 헤더는 키-값 쌍입니다. Wikipedia 페이지 에서 가장 일반적인 제목 목록을 읽을 수 있습니다 . REST를 사용하면 클라이언트가 서버에 대한 요청에 Accept 헤더를 보낼 수 있는 경우가 많습니다. 클라이언트가 어떤 형식으로 응답을 받을 것으로 예상하는지 서버에 알려야 합니다. MIME 유형 목록에는 다양한 형식 옵션이 제공됩니다. MIME (다목적 인터넷 메일 확장)은 인터넷을 통해 보낼 수 있도록 정보를 인코딩하고 메시지 형식을 지정하기 위한 사양입니다. 각 MIME 유형은 슬래시로 구분된 유형과 하위 유형의 두 부분으로 구성됩니다. 다양한 파일 유형에 대한 MIME 유형의 예:

• 텍스트 - 텍스트/일반, 텍스트/CSS, 텍스트/html;
• 이미지 - 이미지/png, 이미지/jpeg, 이미지/gif;
• 오디오 - 오디오/wav, 오디오/mpeg;
• 비디오 - 비디오/mp4, 비디오/ogg;
• 애플리케이션 - 애플리케이션/json, 애플리케이션/pdf, 애플리케이션/xml, 애플리케이션/옥텟-스트림.

전체적으로 요청에는 다음 헤더가 있을 수 있습니다.

Accept:application/json

이 헤더는 클라이언트가 JSON 형식의 응답을 받을 것으로 예상한다는 것을 서버에 알려줍니다.

요청 본문

클라이언트가 서버로 보낸 메시지입니다. 요청에 본문이 있는지 여부는 HTTP 요청 유형에 따라 다릅니다. 예를 들어 GET 및 DELETE 요청은 일반적으로 요청 본문을 포함하지 않습니다. 그러나 PUT 및 POST에는 다음이 포함될 수 있습니다. 이는 모두 요청 유형의 기능적 목적에 관한 것입니다. 결국, id(URL로 전송되는)로 데이터를 받고 삭제하기 위해서는 서버에 추가 데이터를 보낼 필요가 없습니다. 하지만 새 리소스(POST 요청)를 생성하려면 이 리소스를 전송해야 합니다. 기존 리소스를 수정하는 경우에도 마찬가지입니다. REST에서는 요청 본문을 전송하는 데 XML 또는 JSON 형식이 가장 자주 사용됩니다. 가장 일반적인 형식은 JSON입니다. 서버에 요청을 보내고 그 안에서 새 리소스를 생성한다고 가정해 보겠습니다. 기억하신다면, 우리는 고객 주문을 관리하는 애플리케이션을 예로 살펴보았습니다. 새 클라이언트를 생성한다고 가정해 보겠습니다. 우리의 경우 클라이언트에 대해 다음 정보를 저장합니다. 이름 이메일 전화번호 그러한 요청의 본문은 다음 JSON이 될 수 있습니다.

{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+7 (191) 746-43-23"
}

요청 종합

그래서 우리는 클라이언트 요청이 무엇으로 구성될 수 있는지 살펴보았습니다. 이제 설명이 포함된 쿼리의 몇 가지 예를 살펴보겠습니다.

답변

서버의 응답에 대해 몇 마디 말해보자. 대답은 일반적으로 다음 부분으로 구성됩니다.

• 응답 코드;
• 헤더;
• 응답 본문.

일반적으로 응답 헤더는 요청 헤더와 크게 다르지 않습니다. 또한 일부 헤더는 응답과 요청 모두에 사용됩니다. 응답 본문에서도 모든 것이 명확하다고 생각합니다. 본문은 클라이언트가 요청한 정보를 반환하는 경우가 많습니다. GET 요청에 대해 동일한 JSON 형식으로 정보가 반환될 수 있습니다. 하지만 마지막 부분은 좀 더 흥미롭습니다.

HTTP 응답 코드

HTTP 응답 코드를 자세히 살펴보겠습니다. 다음은 Wikipedia의 인용문입니다. HTTP 상태 코드는 HTTP 프로토콜을 통한 요청에 대한 서버 응답의 첫 번째 줄의 일부입니다. 10진수 세 자리의 정수입니다. 첫 번째 숫자는 상태의 클래스를 나타냅니다. 응답 코드 뒤에는 일반적으로 공백으로 구분된 영어 설명 문구가 옵니다. 이는 해당 응답자에게 이 특정 응답의 이유를 설명합니다. 예:

• 201 생성됨;
• 401 승인되지 않음;
• 507 저장 공간이 부족합니다.

클라이언트는 요청 결과에 대해 응답 코드를 통해 학습하고 다음에 수행할 작업을 결정합니다. 응답 코드는 여러 그룹으로 나뉩니다.

• 1ХХ - 정보 제공용;
• 2ХХ - 고객 요청의 성공적인 수락 및 처리 사례에 대해 알립니다.
• 3XX - 작업을 성공적으로 완료하려면 일반적으로 다른 URI를 사용하여 다른 요청을 해야 함을 클라이언트에 알립니다.
• 4ХХ - 클라이언트 오류. 예를 들어 클라이언트가 존재하지 않는 리소스를 요청할 때 발생할 수 있는 잘못 구성된 요청이나 잘 알려진 404 찾을 수 없음 코드가 있습니다.
• 5ХХ - 서버 오류. 서버 오류로 인해 작업이 실패한 경우 클라이언트에 반환됩니다.

여기에서 모든 코드에 대한 자세한 내용을 읽을 수 있습니다 . 1부: REST란 무엇입니까 3부: Spring Boot에서 RESTful 서비스 만들기