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

REST 개요. 파트 1: REST란 무엇입니까? 이 부분에서는 클라이언트와 서버 간에 통신이 이루어지는 방식에 대해 자세히 설명합니다. 그 과정에서 우리는 새로운 용어를 발견하고 설명할 것입니다. REST 개요. 2부: 클라이언트와 서버 간의 통신 - 1

모든 것이 명확한지 확인하기 위해 RESTful 애플리케이션을 예로 사용하여 클라이언트-서버 통신을 분석합니다. 고객 및 주문에 대한 정보를 저장하는 웹 애플리케이션을 개발 중이라고 가정합니다. 즉, 우리 시스템은 특정 엔터티에 대한 작업을 수행할 수 있습니다. 즉, 엔터티를 생성, 편집 및 삭제하고 엔터티에 대한 정보를 표시할 수 있습니다. 이러한 엔터티는 다음과 같습니다.

고객 (고객)
주문(고객 주문)
항목 (제품)

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

요청

클라이언트 요청은 거의 항상 HTTP 프로토콜을 사용하여 이루어집니다. 일반적으로 HTTP 요청은 여러 구성 요소로 구성됩니다.

HTTP 방식
머리글
URI
요청 본문

아래에서 우리는 각 구성 요소를 더 자세히 고려할 것입니다.

URI 및 리소스

클라이언트가 요청을 통해 수신하거나 수정하는 데이터를 리소스라고 합니다. 클라이언트-서버 통신은 리소스 조작에 관한 것입니다. REST에서 리소스는 이름을 지정할 수 있는 모든 것입니다. 어떤 의미에서 그것들은 Java의 클래스와 같습니다. Java에서는 무엇이든 클래스를 만들 수 있습니다. 따라서 REST에서 리소스는 사용자, 문서, 보고서, 주문 등 무엇이든 될 수 있습니다. 일부 엔터티의 추상화이거나 이미지, 비디오, 애니메이션 또는 PDF 파일과 같은 특정 항목일 수 있습니다. 이 예에는 3개의 리소스가 있습니다.

고객 (고객)
주문(고객 주문)
항목 (제품)

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

/customers — 사용 가능한 모든 고객의 URI
/customers/23 — 특정 고객의 URI, 즉 ID=23인 고객
/customers/4 — 특정 고객의 URI, 즉 ID가 4인 고객.

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

/customers/4/orders — 4번 고객의 모든 주문 URI
/customers/1/orders/12 — 1번 고객이 주문한 12번 주문의 URI.

더 많은 제품을 추가하여 확장을 계속하면 다음과 같은 이점이 있습니다.

/customers/1/orders/12/items — 1번 고객이 주문한 12번 주문의 모든 제품 목록 URI.

중첩 수준을 추가할 때 중요한 것은 URI를 직관적으로 만드는 것입니다.

HTTP 방식

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

GET — 특정 리소스(해당 ID를 통해) 또는 리소스 모음에 대한 정보 가져오기
POST — 새 리소스 만들기
PUT — 리소스 변경(ID를 통해)
DELETE — 리소스 삭제(ID를 통해)

헤더

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

텍스트 — 텍스트/일반, 텍스트/css, 텍스트/html
이미지 — 이미지/png, 이미지/jpeg, 이미지/gif
오디오 — 오디오/wav, 오디오/mpeg
비디오 — 비디오/mp4, 비디오/ogg
애플리케이션 — 애플리케이션/json, 애플리케이션/pdf, 애플리케이션/xml, 애플리케이션/octet-stream

예를 들어 요청에는 다음과 같은 헤더가 있을 수 있습니다.

Accept:application/json

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

요청 본문

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

{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+1 (222) 333-4444"
}

요청 모으기

그래서 우리는 클라이언트 요청에 무엇이 있는지 조사했습니다. 이제 설명과 함께 요청의 몇 가지 예를 제공합니다.

요구	설명
`GET /customers/23 Accept : application/json, application/xml`	23번 고객에 대한 정보를 JSON 또는 XML 형식으로 가져옵니다.
`POST /customers { "name" : "Amigo", "email" : "amigo@jr.com", "phone" : "+1 (222) 333-4444" }`	다음 필드를 사용하여 새 고객을 만듭니다. 이름 — Amigo 이메일 — amigo@jr.com 전화 번호 — +1 (222) 333-4444
`PUT /customers/1 { "name" : "Ben", "email" : "bigben@jr.com", "phone" : "+86 (868) 686-8686" }`	고객 번호 1을 다음과 같이 편집합니다. 이름 — Ben 이메일 — bigben@jr.com 전화 번호 — +86 (868) 686-8686
`DELETE /customers/12/orders/6`	12번 고객이 주문한 6번 주문을 시스템에서 삭제

응답

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

응답 코드
헤더
응답 본문

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

HTTP 응답 코드

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

201 생성됨
401 무단
507 스토리지 부족

응답 코드는 클라이언트에게 요청 결과를 알려주고 다음에 수행할 작업을 결정할 수 있도록 합니다. 응답 코드는 여러 클래스 또는 그룹으로 나뉩니다.

1XX — 정보 제공
2XX — 이 코드는 클라이언트의 요청이 성공적으로 수신 및 처리되었음을 나타냅니다.
3XX — 이 코드는 클라이언트에게 작업을 성공적으로 완료하기 위해 일반적으로 다른 URI에 대한 추가 요청을 해야 함을 알립니다.
4XX — 클라이언트 오류. 이러한 코드는 잘못 구성된 요청으로 인해 발생할 수 있습니다. 또 다른 예는 클라이언트가 존재하지 않는 리소스를 요청할 때 발생할 수 있는 잘 알려진 "404 Not Found" 코드입니다.
5XX — 서버 오류. 이 코드는 서버가 작업 실패에 대한 책임이 있는 경우 클라이언트로 반환됩니다.

REST 개요. 3부: Spring Boot에서 RESTful 서비스 구축