REST API 이론

첫 번째 모듈은 HTTP 요청을 생성하고 전송하고 응답을 받는 것으로 끝났습니다.

우리는 앞으로 이것을 더 많이 할 것입니다. 우리는 제3자 서버에 요청을 보낼 것입니다. 우리는 스스로 그러한 요청을 수락하고 응답을 반환하는 응용 프로그램을 만들 것입니다. 우리는 요청을 처리하기 위한 복잡한 논리를 만들 것입니다.

따라서 이러한 요청과 관련된 모든 것을 철저히 연구하여 자세히 분석하는 것이 좋습니다. 요청을 어딘가에 복사하고 반복할 수는 없지만 모든 것이 어떻게 작동하는지 실제로 알아낼 수 있습니다.

이것이 우리가 두 번째 모듈에서 할 일입니다. 갑시다!

일반 이론

이론부터 시작하겠습니다.

첫 번째 모듈에서 숙제를 하고 문서를 공부했다면 약어 API를 눈치채셨을 것입니다. 실제로 개발자가 네트워크의 일부 서비스 또는 응용 프로그램과의 상호 작용을 이해하려는 경우 가장 먼저 연구해야 하는 것은 API 문서입니다.

API

API - 응용 프로그래밍 인터페이스 . 이것은 클라이언트와 서버가 서로 통신할 수 있는 방법에 대한 설명입니다. API 문서를 열고 거기에서 서버에서 필요한 데이터를 얻는 방법을 배웁니다.

우리는 항상 이 상호작용이 간단하고 이해하기를 원합니다. 이것은 개발자(새로운 서비스를 디자인할 때 바퀴를 재발명할 필요가 없음)와 사용자(이전에 친숙한 서비스와 동일한 원리로 작동하는 서비스가 훨씬 더 배우기 쉽습니다) 모두의 작업을 단순화합니다. 그리고 여기서 REST라는 새로운 용어를 기억할 가치가 있습니다.

쉬다

REST - Representational State Transfer 의 약어. 명확하게 들리지 않을 수 있지만 간단히 말해서 REST는 클라이언트와 서버 간의 상호 작용(정보 교환) 스타일입니다.

이것은 엄격한 규칙 및 요구 사항 집합이 아닙니다. REST는 특정 프로그래밍 언어의 사용을 강요하지 않으며 엄격한 지침으로 손을 묶지 않습니다. REST는 아키텍처 스타일이라고 하며 시스템 아키텍처가 준수해야 하는 6가지 원칙을 정의합니다.

따라서 REST의 원리를 고려하여 개발된 API를 REST API 라고 하며, 애플리케이션 자체를 RESTful 이라고 합니다.

우리는 바로 그러한 RESTful 애플리케이션을 만들 것이므로 그들이 즉시 준수할 원칙에 대해 논의할 가치가 있습니다.

RESTful 원칙

클라이언트-서버 모델 . 원칙은 클라이언트와 서버의 분리, 요구 사항의 차별화를 정의합니다. 클라이언트는 데이터가 저장되는 방식에 대해 걱정할 필요가 없습니다. 중요한 것은 요청 시 데이터가 발행된다는 것입니다. 결과적으로 서버는 클라이언트가 이 데이터로 무엇을 할지, 어떻게 처리하고 표시할지 신경 쓰지 않습니다. 이를 통해 서로 독립적으로 개발할 수 있으며 시스템의 확장성이 향상됩니다.

무국적자 . 이 원칙은 서버가 이 클라이언트에 대한 이전 경험을 기반으로 응답을 "생각"해서는 안 된다는 것을 의미합니다. 모든 요청은 이전 요청에 관계없이 처리에 필요한 모든 정보를 포함하는 방식으로 이루어집니다.

캐싱 . 전송되는 데이터를 최소화하기 위해 캐싱 메커니즘이 있습니다. 예를 들어 어떤 페이지에 로고가 표시되면 매번 서버에 로고를 요청하는 것은 의미가 없습니다. 너무 자주 변경되지 않으므로 한 번 가져 와서 클라이언트 컴퓨터의 캐시에 저장하면 충분합니다. 그러나 자동차의 현재 속도에 대한 정보를 얻어야 한다면 캐시는 어떤 식으로든 도움이 되지 않습니다. 이 원칙은 서버에서 전송하는 데이터를 캐시 가능으로 지정해야 하는지 여부를 결정합니다.

균일한 인터페이스 . 이 원칙은 클라이언트-서버 상호 작용의 단일 형식을 정의합니다. 모든 요청의 구조는 동일해야 합니다. 데이터를 요청하는 사람에 관계없이 동일한 형식으로 데이터를 보내야 합니다.

계층화된 시스템 . 클라이언트와 서버가 반드시 직접 통신하는 것은 아닙니다. 데이터 전송은 여러 중간 노드를 통과할 수 있습니다. 이 경우 시스템은 클라이언트와 서버 모두 최종 응용 프로그램과 상호 작용하는지 아니면 중간 노드와 상호 작용하는지 알 수 없도록 설계되었습니다. 이를 통해 서버의 로드 균형을 조정하고 확장성을 높일 수 있습니다.

주문형 코드(선택 사항) . 필수가 아닌 유일한 원칙. 이에 따르면 클라이언트는 서버에서 실행 코드(예: 스크립트)를 다운로드하여 기능을 확장할 수 있습니다. 이 경우 코드는 요청 시에만 실행되어야 합니다.