여러 플랫폼 간의 데이터 교환은 통합 시대에 그 어느 때보다 중요합니다. 통합이 없는 온라인 상점 을 고려하십시오. 귀하의 웹사이트는 제품 목록 관리 외에 사용자 계정, 이메일 구독, 지불 처리 , 배송 및 기타 작업을 관리하기 위한 시스템을 개발해야 합니다. 확장 가능한 옵션이 아니기 때문에 이러한 의무를 다른 공급자에게 아웃소싱하는 것이 더 효과적입니다.
애플리케이션 프로그래밍 인터페이스 또는 웹 API는 소프트웨어 프로그램이 서로 통신하는 데 사용하는 것입니다. API는 두 프로그램 간에 데이터를 교환하기 위한 일관된 프로토콜을 제공합니다. 웹 API의 도움으로 온라인 상점은 배달 소프트웨어, 클라이언트 응용 프로그램, 지불 응용 프로그램 및 기타 필요한 연결과 통신할 수 있습니다.
API를 만드는 방법은 다양합니다. 그러나 서비스에 소프트웨어 연결을 추가하려면 REST API 웹 서비스에 익숙해져야 하는 고유한 기술이 있습니다. 이 기사에서는 REST API 예제, REST API가 무엇인지, REST API가 작동하는 방식, REST API가 사용되는 용도, 기록, 해당 요소 등에 대해 설명합니다.
REST API란 정확히 무엇입니까?
Representational state transfer 또는 REST API 웹 서비스는 앱을 통합할 수 있는 다양하고 이식 가능한 방법을 제공하기 때문에 마이크로서비스 프레임워크에서 구성 요소를 연결하는 가장 표준적인 방법입니다. REST는 표준화되고 예측 가능한 방식으로 내부 및 외부 이해 관계자와 상호 작용하기 위해 사용하는 인기 있는 API 디자인입니다.
웹 애플리케이션 사용자는 REST API 웹 서비스를 사용하여 서로 통신하는 경우가 많습니다. 예를 들어, 소셜 미디어 프로그램에서 계정 세부 정보를 획득하고 검토합니다. REST API 브라우저는 웹의 구문으로 볼 수 있습니다. 온라인 고객은 웹 API를 활용하여 클라우드 사용량이 증가함에 따라 디지털 작업에 대한 액세스를 제공하고 관리합니다.
고객이 분산된 컨텍스트에서 동적으로 디지털 웹 서비스에 연결, 관리 및 참여할 수 있도록 하는 웹 API를 설계하는 것은 합리적인 결정입니다. Google, eBay, Facebook, Amazon 및 Twitter와 같은 웹 사이트는 RESTful 웹 서비스를 사용합니다. 클라이언트 애플리케이션은 이제 REST를 사용하여 이러한 웹 서비스에 액세스할 수 있습니다.
REST 기술은 다른 관련 기술보다 선호됩니다. REST 웹 서비스는 대역폭을 덜 사용하므로 효율적인 온라인 활동에 이상적입니다. RESTful 웹 서비스는 JavaScript 또는 Python과 같은 프로그래밍 언어를 사용하여 개발할 수도 있습니다.
REST API는 어떻게 작동합니까?
REST API 가 어떻게 작동하는지 알기 위해 몇 가지 핵심 용어를 정의해야 합니다.
고객
API 사용자를 클라이언트라고 합니다. 클라이언트는 데이터를 가져오거나 프로그램에 수정 사항을 적용하기 위해 웹 API에 쿼리를 보냅니다. 귀하의 인터넷 브라우저는 클라이언트입니다. 다양한 웹 API와 통신하여 페이지 콘텐츠를 얻습니다. 컴퓨터가 필요한 정보를 수신한 다음 디스플레이에 표시됩니다.
다음은 가장 많이 사용되는 HTTP 메서드입니다.
- GET 요청을 사용하여 요청된 데이터 또는 요청된 리소스를 반환합니다.
- POST 요청을 사용하여 새 리소스 만들기
- PUT 명령을 사용하여 기존 리소스를 변경하거나 계속 업데이트합니다.
- DELETE 명령을 사용하여 리소스를 제거합니다.
예를 들어 Youtube의 API에 대한 HTTP 요청은 특정 비디오나 게시물에 대한 GET 요청 리소스 또는 새 사진을 게시하기 위한 POST 요청이 될 수 있습니다. POST 요청 방법을 사용하여 새 게시물을 게시할 수 있습니다. 이에 따라 자동 교환 구현과 통합되는 고객 웹 서비스 플랫폼은 PUT 명령을 사용하여 사용자 지정 Hello를 업데이트하거나 제거할 수 있습니다.
요청 받기
- GET 요청 캐싱이 가능합니다. 브라우저의 이력에는 GET 요청이 포함됩니다.
- GET 요청을 북마크에 추가할 수 있습니다.
- 중요한 자료로 작업하는 동안 GET 요청을 사용하지 마십시오.
- GET 요청에는 길이 제한이 있습니다.
- 데이터 쿼리만 GET 요청을 통해 이루어집니다.
POST 방식
POST 요청은 리소스를 추가하거나 업데이트하기 위해 서버에 정보를 보내는 게시 방법입니다. HTTP 요청의 요청 본문에는 서버 측에 게시되는 데이터가 포함됩니다.
- POST 요청 게시 메서드는 캐시로 이동하지 않습니다.
- POST 요청은 브라우저 기록에 저장되지 않습니다.
- POST 요청은 북마크할 수 없습니다.
응답 본문
응답 본문은 RESTful API의 중요한 요소 중 하나입니다. 요청된 데이터는 응답 본문에 포함됩니다. 응답 본문은 출력 및 출력 논리 포트에 관한 데이터를 포함할 수 있습니다.
자원
Web API가 사용자에게 제공할 수 있는 모든 데이터는 리소스입니다. 예를 들어 개인, 페이지, 사진 또는 발언은 모두 Facebook API에서 리소스로 간주될 수 있습니다. 리소스 식별자는 각 리소스에 지정된 특수 용어입니다.
웹 서버
고객 요청 본문을 수락하는 프로그램은 소비자가 요청하는 리소스가 있는 웹 서버를 사용합니다. 서버는 고객에게 데이터베이스 에 보관된 정보에 대한 즉각적인 액세스를 제공하지 않고도 API를 통해 클라이언트와 통신할 수 있습니다. 사용자가 RESTful 웹 서비스에 액세스하여 요청 본문을 제출하면 서버는 리소스 상태에 대한 정규화된 설명을 브라우저에 보냅니다.
이것은 서버가 어떻게든 정확한 자원을 클라이언트에 제출하지 않고 오히려 그 조건, 즉 특정 타임스탬프에서 자원의 상황을 반영한다는 것을 의미합니다. 이해를 돕기 위해 응답은 간단한 형식으로 반환됩니다.
JSON(JavaScript Object Notation)은 사람과 기계가 모두 읽을 수 있고 웹 접근성을 높이는 데 탁월하기 때문에 널리 사용됩니다. JSON은 주로 웹 애플리케이션 및 클라이언트 애플리케이션에서 요청 본문을 보내는 데 사용됩니다. 다양한 코딩과 호환되는 형태입니다. JSON 이외의 API 데이터 형식에는 XML , YAML, CSV, HTML 및 일반 텍스트가 포함됩니다. API 사용자는 맞춤형 미디어 유형을 사용하여 원하는 데이터 형식을 선택할 수 있습니다.
REST API의 역사
많은 프로그래머는 API를 통합하기 위해 REST 이전에 SOAP로 작업해야 했습니다. SOAP 구축, 활용 및 디버깅은 악명 높은 어려운 작업이었습니다. 고맙게도 REST는 Roy Fielding의 지시 하에 프로그래머 팀에 의해 개발되어 API 환경을 영원히 변경했습니다.
시간 경과에 따른 REST API 개발 연대기는 다음과 같습니다.
휴식 전
프로그래머는 SOAP를 사용하여 웹 API를 연결하기 위해 콘텐츠 내부에 원격 프로시저 호출(RPC)이 포함된 XML 파일을 수동으로 작성했습니다. 그런 다음 디자이너는 SOAP 패키지를 지정된 끝점에 POST합니다.
2000년에
Roy Fielding이 이끄는 프로그래머 팀은 모든 서버가 다른 서버와 통신할 수 있는 프레임워크를 개발하기로 결정했습니다. 그는 REST API에 대한 제한 사항을 설정했습니다. 이러한 지침은 보편적이기 때문에 소프트웨어 개발이 더 쉽습니다.
2002년에
eBay는 2002년 RESTful API를 개발하여 혜택을 받을 수 있는 모든 웹사이트에 시장을 개방했습니다. 이 때문에 전자 상거래의 또 다른 거물인 Amazon이 이에 관심을 갖게 되었고 2002년 RESTful API를 출시했습니다.
2004-2006년에
Flickr의 RESTful 웹 서비스는 2004년에 출시되어 작가가 웹사이트와 소셜 미디어 게시물에 사진을 빠르게 추가할 수 있게 되었습니다. Twitter와 Facebook은 상당한 수의 프로그래머가 웹사이트를 스캔하고 "Frankenstein" API를 만들고 있음을 알았을 때 약 2년 후에 둘 다 API를 공개했습니다.
2006년~현재
RESTful 웹 서비스는 이제 앱과 사이트의 성능을 개선하기 위해 이러한 RESTful 웹 서비스를 사용하는 프로그래머들에 의해 널리 받아들여지고 있습니다. AppMaster는 협업을 용이하게 하고 API를 더 쉽게 구성할 수 있도록 하여 더 빠르게 수행할 수 있도록 합니다.
REST API는 무엇에 사용됩니까?
RESTful 웹 서비스의 주요 이점 중 하나는 상당한 유연성을 제공하여 이 RESTful API를 보다 효과적으로 사용할 수 있다는 것입니다. 다음은 REST API가 사용되는 일부 REST API 예입니다.
클라우드 기반 애플리케이션
호출의 상태 비저장으로 인해 REST API는 클라우드 애플리케이션에서 유리합니다. 상태 비저장 모듈은 문제가 발생하는 경우 용량 요구 사항을 충족하도록 쉽게 다시 설치하고 확장할 수 있습니다. 로컬 및 인터넷 기반 구성 요소를 결합한 소프트웨어 프로그램은 클라우드 응용 프로그램입니다. 이 패러다임은 웹 브라우저에서 액세스하는 원격 서버와 지속적인 인터넷 웹 서비스를 사용하여 명령을 실행합니다.
클라우드 애플리케이션 호스트의 기존 위치는 타사 클라우드 컴퓨팅 네트워크 운영자가 실행하는 원격 컴퓨터 시스템입니다. 메일, 문서 공유 및 저장, 주문 입력, 재고 관리, Microsoft Word, CRM (고객 관계 관리), 정보 수집, 재무 및 회계는 클라우드 기반 애플리케이션으로 수행되는 작업의 예입니다.
REST API (응용 프로그래밍 인터페이스)를 사용하여 정보 및 스토리지 리소스의 외부 소스를 연결할 수 있습니다. 프로그래머는 REST API를 사용하여 클라우드 앱을 더 작게 만들어 계산을 처리하거나 분석하고 소프트웨어 프로그램에 결과를 반환하기 위해 데이터를 다른 프로그램으로 전송할 수 있습니다. 테스트된 API는 활성 균일성을 적용하여 생산을 가속화하고 실제 결과를 생성할 수 있습니다.
클라우드 애플리케이션의 대표적인 예는 Google 문서 또는 Office 365입니다. Google 문서 또는 Office 365에 필요한 것은 검색 엔진과 인터넷 웹 서비스를 실행할 수 있는 컴퓨터뿐입니다. 컴퓨터 네트워크는 정보 저장을 포함한 사용자 인터페이스와 작업을 제공합니다. 클라우드 애플리케이션 호스트를 사용하여 회사에서 수많은 고유한 클라우드 앱을 호스팅할 수 있습니다.
클라우드 서비스
API를 통해 리소스에 연결하려면 URL이 처리되는 방식을 관리해야 하므로 REST API는 클라우드 웹 서비스에도 유용합니다. RESTful 웹 서비스 아키텍처는 클라우드 애플리케이션으로 인해 미래에 표준이 될 가능성이 높습니다. 프로그래머는 RESTful 웹 서비스를 사용하여 인터넷을 통해 클라우드 서비스에 연결합니다. 개발자는 인터넷 공급자의 API를 사용하는 코드를 만들고 필요한 입력과 변수를 제공한 다음 응답을 확인하여 작업이 예상대로 작동하는지 확인합니다.
최종 사용자는 RESTful 웹 서비스와 같은 클라우드 서비스를 사용하여 컴퓨팅 인프라, 스토리지 시스템 또는 추적 시스템과 같은 클라우드 웹 서비스에서 제공하는 클라이언트 애플리케이션 또는 웹 서비스에 액세스할 수 있습니다. API는 응용 프로그램의 기능과 작업, 그리고 이를 수행하는 데 필요한 세부 사항을 간략하게 설명합니다. 클라이언트 개인 정보 보호 및 보안을 유지하기 위해 API는 종종 REST 또는 SOAP(Simple Object Access Protocol) 상호 운용성 및 OAuth 2.0과 같은 권한 메커니즘에 의존합니다.
다양한 웹 서비스를 "클라우드 서비스"라고 하며 요청 시 기업과 소비자가 온라인으로 사용할 수 있습니다. 이러한 웹 서비스는 하드웨어나 인프라 없이도 도구와 앱에 빠르고 저렴하게 액세스할 수 있도록 만들어졌습니다. 대부분의 직원은 이메일에서 문서 공동 작업에 이르기까지 모든 작업에 클라우드 웹 서비스를 사용합니다.
웹 사용
REST는 클라이언트 측 기능에 종속되지 않으므로 이러한 웹 API는 사용자 웹 프로젝트, iPhone 앱 , IoT 장치 또는 Windows Mobile에서 얻을 수 있습니다. 특정 클라이언트 측 프레임워크에 제약을 받지 않고 비즈니스를 위한 아키텍처를 만들 수 있습니다.
REST API 예제
REST API 예제를 살펴보겠습니다. Open Trivia Database 임의 인텔리전스 문의는 아래 링크를 클릭하세요. 이러한 RESTful 웹 서비스는 공개 웹 API를 제공하는 데 사용되었습니다. 컴퓨터에 단일 퀴즈 질문과 해당 응답이 JSON 형식으로 표시됩니다.
url과 같은 HTTP 브라우저를 사용하여 다음 쿼리를 실행하고 응답 본문에서 응답을 받을 수 있습니다. https://opentdb.com/api.php?amount=1&category=18
웹 서비스 XML 파일의 응답 본문에는 모든 직원 정보가 포함됩니다.
널리 사용되는 모든 프로그래밍 언어와 개발자 도구에는 JavaScript, Node.js 및 Deno의 검색 및 PHP의 file get contents()와 같은 HTTP 클라이언트 라이브러리가 있습니다. JSON 답변은 HTML 또는 다른 스타일로 표시되기 전에 기계에서 읽을 수 있으므로 읽고 사용할 수 있습니다.
나머지 및 REST API
시간이 지남에 따라 많은 데이터 전송 방법이 개발되었습니다. CORBA, SOAP 또는 XML-RPC와 같은 선택 항목이 있을 수 있습니다. 가장 많이 개발된 엄격한 메시지 지침. Roy Fielding은 2000년에 REST를 처음으로 설명했는데, 이는 다른 것보다 훨씬 간단합니다.
표준이 아닌 RESTful 웹 서비스에 대한 제안 및 제한 사항 모음입니다. 다음과 같은 아키텍처 제약 조건으로 구성됩니다.
클라이언트-서버 파티션
클라이언트와 웹 서버는 REST 아키텍처에서 한 방향으로만 통신할 수 있습니다. 클라이언트는 도메인 컨트롤러를 요청하고 컨트롤러 또는 서버는 요청에 응답합니다. 웹 서버는 요청을 제출할 수 없으며 고객은 대응할 수 없습니다. 소비자는 모든 연결을 시작합니다.
RESTful 웹 서비스는 고객과 서버 간의 상호 작용을 용이하게 하여 격리된 상태로 유지합니다. 클라이언트 컴퓨터는 다른 호스팅에 영향을 미칠 염려 없이 개발할 수 있으며 서버 자료는 고객에게 무심코 영향을 미치지 않고 변경할 수 있습니다.
균일한 인터페이스
이 전략에 따르면 모든 쿼리와 반응은 표준 proweb 절차를 따르거나 메시지 스타일을 지정해야 합니다. 앱과 서버는 중재자를 통해 서로 성능이 좋지 않은 다양한 프로그래밍 언어로 개발됩니다. 균일한 인터페이스는 모든 고객이 REST API와 상호 작용하는 데 사용할 수 있는 방언입니다.
정규화된 상호 작용이 있는 응용 프로그램 간의 요청 및 반응 번역만 가능합니다. 사소한 차이점으로 인해 정보가 뒤죽박죽이 되어 손실될 수 있으며, 웹 API가 수정하면 솔루션은 요청 절차를 업그레이드해야 합니다. 일관된 인터페이스는 이러한 가능성을 제거합니다.
https://www.googleapis.com/youtube/v3/channels?part=contentDetails 에 액세스
모든 REST 클라이언트 애플리케이션과 마찬가지로 이 제안에는 두 가지 데이터가 포함됩니다. HTTP 기술은 GET입니다. 이것은 클라이언트가 리소스에 대해 수행하려는 작업을 설명합니다. 사용자는 네 가지 기본 HTTP 메서드를 만들 수 있습니다.
HTTP 또는 Hyper-Text Transfer Protocol은 대부분의 REST API에 대한 범용 언어입니다. HTTP는 REST를 염두에 두고 설계되지 않았습니다. 또한 REST는 이 데이터 전송을 REST 인식 앱의 기준으로 받아들였습니다. REST API와 함께 HTTP를 사용하기 위해 클라이언트는 친숙한 형식으로 요청을 제출합니다. 예를 들어 YouTube API에 대한 비디오 신호 요청은 다음과 같습니다.
- 리소스를 얻으려면 GET 명령을 사용하십시오.
- POST 명령을 사용하여 새 리소스 만들기
- PUT 명령을 사용하여 기존 리소스를 변경하거나 계속 업데이트합니다.
- DELETE 요청을 사용하여 리소스를 제거합니다.
HTTP 메서드는 특정 리소스와 관련하여 수행할 의도된 작업을 지정합니다. HTTP 메서드는 HTTB 동사라고도 합니다.
URL은 HTTP입니다.
의도한 리소스를 식별하는 URI(Uniform Resource Identifier)가 URL에 포함되어 있습니다. URL은 RESTful API가 서비스 사용자와 연결되는 곳이므로 이 시나리오에서 끝점이기도 합니다.
쿼리 문자열: URL에는 쿼리 문자열이 포함됩니다. 쿼리 문자열은 값이 지정된 매개변수를 정의하는 데 사용됩니다.
요청을 수신하고 확인한 후 웹 서버는 대상 리소스의 데이터를 되돌립니다. 일반적으로 데이터는 JSON(JavaScript Object Notation)이라는 구조로 반환됩니다. JSON은 리소스의 모든 구성 요소를 인간이 쉽게 읽을 수 있는 이식 가능한 형식으로 제공합니다.
균일한 인터페이스의 원리
균일한 인터페이스는 다음 매개변수를 따라야 합니다.
HATEOAS: 애플리케이션 상태의 엔진으로서의 하이퍼미디어
Hypermedia는 RESTful 웹 서비스의 엔진입니다. 이것은 하이퍼미디어가 공급자의 대답을 인식하기 위해 고객이 이해하기를 원하는 모든 것임을 나타냅니다.
- 클라이언트 응용 프로그램의 첫 번째 URI만 클라이언트에 제공해야 합니다. 클라이언트 애플리케이션은 하이퍼링크를 사용하여 다른 모든 자료와 활동을 지속적으로 구동해야 합니다.
- RESTful 웹 서비스는 다른 API와 달리 입력 쿼리 언어(IDL)가 필요하지 않습니다.
미디어 유형은 표현의 데이터 형식에 대한 이름입니다. 미디어 유형은 묘사를 처리해야 하는 방법을 설명하는 정의를 식별합니다. REST를 사용하는 웹 API는 하이퍼텍스트처럼 보입니다. 주소가 지정될 수 있는 모든 데이터 항목은 직접(예: 링크 및 ID 속성을 통해) 또는 암시적으로(예: 미디어 유형 설명 구조에서 파생됨) 위치를 포함합니다.
자기 설명 메시지
클라이언트 측과 서버 측 간의 각 통신은 통신을 실행하기에 충분한 데이터를 제공해야 합니다. 따라서 클라이언트 측에서 서버 측으로의 요청은 특정 목표와 함께 액세스하려는 리소스를 지정해야 합니다.
또한 리소스 설명은 자체 설명적이어야 합니다. 사용자는 리소스가 사람인지 장비인지 알 필요가 없습니다. 대신 도움말에 연결된 미디어 유형에 따라 응답해야 합니다.
따라서 틀림없이 우리는 많은 고유한 미디어 유형을 개발할 것이며 종종 리소스당 하나의 미디어 유형을 개발할 것입니다. 모든 형태의 미디어는 표준 제작 패러다임을 지정합니다. 예를 들어 HTML은 하이퍼텍스트가 표시되는 방식과 브라우저가 각 구성 요소를 처리하는 방식을 정의합니다.리소스 식별
고객과 서버 간의 후방 통신에서 참조되는 리소스는 묘사를 사용하여 인식할 수 있어야 합니다. 이를 위해 URI(Uniform Resource Identifier) 시스템을 고수했습니다. 즉, 서버에서 고객으로의 통신에는 서버 저장소의 실제 파일이 아닌 문서의 HTML 버전과 일부 정보가 포함될 수 있습니다.
소비자는 URI 패턴을 따르기 때문에 HTML 버전을 쉽게 이해할 수 있습니다. 고객은 리소스가 궁극적으로 어떻게 표시되어야 하는지에 대한 설명을 서버에 제공하여 리소스를 수정해야 합니다. 이렇게 하면 사용자가 리소스를 빌드, 검색, 수정 및 제거할 수 있습니다. 고객이 데이터를 변경하는 데 필요한 권한이 있는 경우 서버는 쿼리를 수행해야 합니다.
무국적자
RESTful API를 사용하면 모든 클라이언트 요청이 일시적이어야 합니다. 결과적으로 각 쿼리 및 응답 본문에는 계약을 체결하는 데 필요한 모든 데이터가 포함되어 각 연결을 자율적으로 만듭니다. 서버는 이전 HTTP 요청을 추적하지 않습니다. 클라이언트가 만든 각 쿼리를 완전히 새로운 쿼리로 취급합니다.
서버는 기록 데이터를 얻기 위해 추가 작업을 수행할 필요가 없기 때문에 상태 비저장 전송은 서버에 필요한 저장 공간의 양을 크게 최소화하고 응답이 허용될 가능성을 높입니다. 이것은 이러한 상호 작용의 확장성을 보장합니다. 프로그래머는 소프트웨어가 확장되고 HTTP 요청을 만들 때 훨씬 더 많은 저장소를 사용하거나 서버에 부담을 주는 것에 대해 걱정할 필요가 없습니다.
레이어드
우리는 지금까지 웹 API 쿼리를 간단한 클라이언트-서버 교환으로 정의했습니다. 이 두 조직 사이에는 종종 더 많은 서버가 있습니다. 이러한 플랫폼 또는 계층은 트래픽을 관리 및 분산하고, 보호 기능을 추가하고, 기타 다양한 중요한 작업을 수행합니다.
이 개념에 따르면 사용자와 대상 서버 간에 전송되는 메시지는 그 사이에 존재하는 계층에 관계없이 유사하게 구조화되고 처리되어야 합니다. 추가 레이어는 고객 상호 작용에 적합해야 합니다. 이 규칙을 따르는 프로그래머는 기본적인 요청-응답 프로세스에 영향을 주지 않고 서버 시스템을 변경할 수 있습니다.
캐시 가능
캐싱은 콘텐츠가 고객의 컴퓨터에 저장될 때 고객이 웹사이트를 탐색할 때 발생합니다. 캐시된 자료는 사용자가 나중에 해당 사이트를 방문할 때 서버에서 다시 다운로드되지 않고 내부 메모리에서 빠르게 로드됩니다. 대부분의 대형 사이트는 캐싱을 사용하여 서버 공간과 대역폭을 보존하면서 페이지 로드를 줄입니다.
REST API를 개발할 때 데이터 캐싱을 고려합니다. 서버가 고객에게 제공하는 응답은 주어진 자원을 저장할 수 있는지 여부와 그 기간을 명시해야 합니다.
주문형 코드
마지막 REST 신조는 필요하지 않습니다. 요청하는 경우 API의 응답에는 클라이언트가 사용할 소프트웨어 코드가 포함될 수 있습니다. 이 때문에 고객은 백엔드에서 클라이언트 애플리케이션이나 프로그램을 실행할 수 있습니다.
API는 이 지침 세트를 준수하는 경우 RESTful API로 간주됩니다. 그러나 이러한 지침은 프로그래머에게 RESTful API의 기능을 수정할 수 있는 많은 자유를 제공합니다. REST API는 더 유연하다는 점에서 또 다른 인기 있는 웹 API 기술인 Simple Object Access Protocol과 다릅니다(SOAP).
엔드포인트 합의
다음 끝점을 고려하십시오.
- /사용자/123\s
- /사용자/ID/123\s
- /user/123\s/user/id/123\s
- /사용자/?id=123
모두 클라이언트(123)가 데이터를 검색하는 합법적인 방법입니다. 절차가 복잡할수록 가능성이 커집니다. 예를 들어, 항목 51에서 시작하는 역순으로 "A"로 시작하고 회사에서 운영되는 성을 가진 10명을 표시합니다.
결국 URL을 구성하는 방법은 중요하지 않습니다. RESTful API 전반에 걸친 균일성이 중요합니다. 많은 프로그래머가 있는 거대한 소프트웨어 시스템에서는 쉽지 않습니다. RESTful API 수정은 불가피하지만 엔드포인트 URL을 거부하면 해당 URL에 의존하는 앱이 작동을 중지하므로 거부해서는 안 됩니다.
REST API 버전 관리
API 버전 관리는 비호환성을 방지하기 위한 일반적인 방법입니다. 예를 들어 /2.0/user/123이 /user/123을 대체합니다. 이전 엔드포인트와 새 엔드포인트 모두 계속 작동할 수 있습니다. 결과적으로 이것은 과거의 중요한 API가 유지되어야 할 필요성을 강요합니다. 이전 버전은 궁극적으로 폐기될 수 있지만 절차를 신중하게 고려해야 합니다.
REST API 인증
모든 장치는 조회 API를 사용하여 승인 없이 Quip을 다운로드할 수 있습니다. 개인 정보를 읽거나 쿼리 편집 및 제거를 허용하는 API는 이를 지원하지 않습니다. RESTful 웹 서비스와 동일한 도메인 내의 클라이언트 측 프로그램은 HTTP 요청과 동일한 방식으로 쿠키를 보내고 받습니다. (Fetch()에 대한 이전 사이트에서 권한 다시 시작 옵션을 지정해야 합니다.) API 쿼리를 확인하여 사용자가 로그인하고 필요한 권한이 있는지 확인할 수 있습니다.
HTTP 기본 인증 : 타사 프로그램은 다른 승인 솔루션을 사용해야 합니다. 몇 가지 인기 있는 인증 방법은 다음에 대한 기본 확인입니다.
- HTTP. base64로 인코딩된 사용자 이름: 암호 문자열은 HTTP 승인 헤더의 일부로 쿼리 필드에 제공됩니다.
- API 키: 특별한 권한이 있거나 단일 사이트로 제한될 수 있는 RESTful API 키를 제공하여 API를 타사 애플리케이션에서 사용할 수 있습니다. 각 메시지에는 쿼리 문자열 또는 HTTP 헤더에 키가 포함되어 있습니다. (쿼리 문자열은 URL의 구성 요소입니다).
- OAuth: 요청을 하기 전에 자격 증명을 얻기 위해 고객 ID와 고객 암호가 OAuth 서버로 전송됩니다. 만료될 때까지 OAuth ID가 각 API 요청과 함께 전송됩니다.
- JWT(Internet Tokens in JSON): 쿼리 헤더와 응답 헤더는 디지털 서명된 사용자 자격 증명을 안전하게 전달합니다. JWT를 사용하면 서버가 액세스 권한을 암호화할 수 있으므로 데이터베이스를 쿼리하거나 다른 인증 메커니즘을 사용할 필요가 없습니다.
사용 시나리오는 API 인증 방식에 영향을 미칩니다.
- 때로는 타사 프로그램이 동일한 권한과 권한을 가진 로그인한 다른 클라이언트처럼 처리됩니다. 예를 들어, 지도 API는 요청 프로그램에 두 지점 간의 지침을 제공할 수 있습니다. 프로그램이 합법적인 사용자인지 확인해야 하지만 클라이언트의 자격 증명을 확인할 필요는 없습니다.
- 다른 상황에서는 타사 프로그램이 메일 콘텐츠와 같은 특정 사용자의 개인 정보를 요청합니다. REST API는 클라이언트와 해당 권한을 인식해야 하지만 호출 프로그램과 관련될 필요는 없습니다.
REST API 보안
RESTful 웹 서비스는 소프트웨어와 상호 작용하고 소프트웨어에 영향을 주는 또 다른 방법을 추가합니다. 호스트가 높은 수준의 해킹 목표가 아니더라도 잘못 행동하는 사용자는 초당 수백 개의 요청을 제출하고 이를 축소할 수 있습니다. 이 문서에서는 보안을 다루지 않지만 표준 최상의 절차에는 다음이 포함됩니다.
HTTPS를 활용하라
강력한 인증 메커니즘 사용
CORS는 고객 호출을 특정 지역으로 제한하는 데 사용할 수 있습니다.
기능의 필수품을 제공하십시오.
필요하지 않은 DELETE 선택을 생성합니다. 모든 엔드포인트 URL 및 본문 정보를 확인합니다.
클라이언트 측 JavaScript에서 API 바우처를 적용하지 않음으로써 식별되지 않은 섹터 또는 IP 주소의 링크를 차단합니다.
비정상적으로 큰 패킷은 차단됩니다.
동일한 IP 주소 또는 API 자격 증명의 요청이 분당 N개의 쿼리로 제한되는 속도 제한에 대해 생각해 보십시오.
적절한 HTTP 상태 코드, 캐시 헤더 로그 쿼리 및 실패한 조사로 응답
다중 요청 및 불필요한 데이터
RESTful 웹 서비스 배포에는 제한 사항이 있습니다. 응답에 요청한 것보다 더 많은 정보가 있거나 모든 정보를 가져오려면 여러 요청이 필요할 수 있습니다. 사용자에게 작성자 및 도서 정보에 대한 액세스를 제공하는 RESTful 웹 서비스에 대해 생각해 보십시오. 클라이언트는 다음을 수행할 수 있습니다.
- 구매 순서대로 나열된 처음 10권의 도서 정보를 요청합니다(최상급 판매자 우선). 각 작가의 ID와 함께 책 모음이 답변에 포함되어 있습니다.
각 작성자에 대한 정보를 검색하려면 최대 10개의 /author/id 쿼리를 작성하십시오.
"N+1 문제"로 특성화되는 상위 쿼리에 대한 각 응답에 대해 N API 쿼리가 생성되어야 합니다.
이것이 자주 사용되는 상황이라면 RESTful 웹 서비스는 이름, 성별, 국가를 포함하여 생산된 모든 책에 대한 모든 작가 정보를 포함하도록 수정될 수 있습니다.성격, 전기 등. 이전 책에 대한 더 많은 정보가 제공될 수 있지만 그렇게 하면 응답 부담이 크게 늘어날 것입니다. 작성자 정보를 선택 사항으로 만들기 위해 API가 변경될 수 있습니다. 저자 세부 정보 = 불필요하게 큰 답변을 방지하기 위해 전체. API 디자이너가 지원해야 하는 옵션의 수는 압도적일 수 있습니다.
마무리
이제 REST API, REST API 작동 방식, REST API 예제, REST API가 사용되는 용도, 아키텍처 제약 조건 및 이 자습서에서 다루는 기타 주제를 완전히 이해했습니다. 프로그래머는 API에 대해 배우는 것이 어렵고 두려울 수 있지만 코드가 없는 플랫폼인 AppMaster는 사용자의 전문성 개발을 지원하기 위해 다양한 REST API에 대한 인식을 심화할 수 있는 새로운 액세스 가능한 REST API 라이브러리를 만들었습니다.
AppMaster에서는 API 접근성과 사용성을 높이기 위해 노력합니다. 우리는 당신이 직업과 개인 생활에서 API 소프트웨어를 사용하는 이점에 대해 배우고 실험하고 깨닫기를 바랍니다. 더 나은 웹 API를 더 빠르게 설계할 수 있도록 AppMaster는 협업을 개선하고 API 수명 주기의 모든 단계를 자동화합니다. REST API에 대한 이해를 계속 만들고 발전시키고 넓히십시오.
