REST 소개

사용 가능

8.1 원격 API 접근 방식

모든 프로그래머는 클라이언트-서버 아키텍처를 구축할 때 동일한 실수를 범합니다. 그들은 서버에 대한 요청을 메소드 호출로 취급하기 시작합니다 .

서버에서 보고서 생성 프로세스를 시작하고 싶은데 다음과 같은 요청을 보내지 않겠습니까?

http://server.com/startDocumentGeneration?params

완료 후 보고서를 다운로드하는 방법은 무엇입니까? 이를 위해 다른 방법을 작성합니다.

http://server.com/getDocument

서버는 HttpSession문서에 대한 정보를 저장하고 문서가 생성되는 즉시 이를 돌려줍니다.

훌륭한 접근 방식입니다. 아님?

접근 방식은 정말 끔찍합니다. 문제는 서버가 문서 번호를 기억해야 한다는 것입니다. 즉, 새로운 메서드 호출을 제대로 처리하기 위해 서버는 이전 메서드 호출 결과를 기억해야 합니다.

웹에서 이것은 큰 문제입니다. 인터넷이 사라지고 브라우저가 닫힐 수 있습니다. 페이지를 다시 로드하거나 실수로 링크를 클릭하는 등의 작업을 수행할 수 있습니다. 그리고 서버는 이전 사용자 요청에서 메가바이트의 데이터를 계속 저장합니다...

서버와의 편안한 작업을 위해 서버에 대한 이전 요청 데이터를 항상 가지고 있을 것이라고 기대할 수 없습니다.

그러면 서버의 메서드를 호출하는 방법은 무엇입니까? 정답은 끔찍할 것입니다. 안 돼요!

8.2 REST 접근법

프로그래머는 기본으로 돌아가 처음에 요청에 서버의 파일 경로가 포함되어 있음을 기억했습니다.

http://server.com/path?params

그리고 우리는 이 접근 방식을 최대한 활용하기로 결정했습니다.

이제 서버는 트리 형태로 외부에 보이는 데이터 저장소로 간주됩니다 .

모든 사용자 목록을 얻으려면 다음 쿼리를 호출하십시오.

http://server.com/users

사용자 113에 대한 데이터를 얻으려면 다음 쿼리를 실행하십시오.

http://server.com/users/113

등등 모두 같은 맥락입니다.

다시 한 번 서버는 트리 형태로 외부에 보이는 데이터 저장소로 보입니다.

데이터는 GET 요청 , 수정된 POST 요청 및 삭제된 DELETE 요청을 수신할 수 있습니다 .

8.3 상태 없음

클라이언트와 서버 간의 REST 프로토콜 상호 작용에는 다음 조건이 필요합니다. 클라이언트의 요청 사이에 클라이언트 상태에 대한 정보가 서버에 저장되지 않습니다.

클라이언트의 모든 요청은 서버가 매번 요청을 수행하는 데 필요한 모든 정보를 받는 방식으로 작성되어야 합니다 . 세션 상태는 클라이언트 측에 저장됩니다.

클라이언트 요청을 처리하는 동안 클라이언트는 전환 상태에 있는 것으로 간주됩니다. 각각의 개별 애플리케이션 상태는 다음에 클라이언트가 적중할 때 호출될 수 있는 링크로 표시됩니다.

8.4 인터페이스 균일성

서버에서 개체를 검색하는 데 사용되는 모든 경로가 표준화됩니다. 이는 특히 다른 REST 서버에서 데이터를 가져오는 경우에 매우 편리합니다.

모든 개체 인터페이스는 세 가지 조건을 준수해야 합니다.

리소스 식별

모든 리소스는 URI를 사용하여 요청에서 식별됩니다. 서버 내부의 리소스는 클라이언트에 반환되는 보기와 별개입니다. 예를 들어 서버는 데이터베이스에서 HTML, XML 또는 JSON으로 데이터를 보낼 수 있으며 둘 다 서버 내의 저장소 유형이 아닙니다.

보기를 통한 리소스 조작

클라이언트가 메타데이터를 포함하여 리소스 표현을 저장하는 경우 서버에서 리소스를 수정하거나 삭제할 수 있는 충분한 정보가 있는 것입니다.

"자체 설명" 메시지

각 메시지에는 처리 방법을 이해하기에 충분한 정보가 포함되어 있습니다. 예를 들어 사용자에 대한 정보가 필요한 경우 서버는 이름, 주소 필드가 있는 JSON 개체를 반환합니다.

클라이언트가 응답의 첫 번째 숫자가 연령이고 두 번째 숫자가 생년월일임을 알 필요가 있는 상황이 있어서는 안 됩니다.

8.5 캐싱

REST 방식은 데이터 요청이 HTTP 프로토콜을 통해 이루어진다고 가정합니다. 따라서 GET 요청을 호출하여 객체를 얻습니다. 즉, GET 요청을 통해 받은 모든 리소스와 마찬가지로 HTTP 리소스 캐싱에 대한 모든 규칙이 적용됩니다.

즉, REST API를 통해 받은 데이터는 웹 서버의 정적 리소스와 동일한 방식으로 캐시됩니다. 아름다움 :)

코멘트
  • 인기
  • 신규
  • 이전
코멘트를 남기려면 로그인 해야 합니다
이 페이지에는 아직 코멘트가 없습니다