실력 향상을 위해 웹 API 입문

개요

'웹 API 제작 도구/서비스를 사용해 보고 싶다','늘 웹 API를 사용한 것 같지만 다른 사람이 말하는 대로 URL을 두드리는 것뿐'이라는 사람(자신 포함)에 대해 웹 API가 조금 이해할 수 있는 기사를 썼다.
(대략적인 프로세스에만 초점을 맞추기 때문에 REST에 접근하지 않습니다.)

도대체 무엇을 위해 존재하는 것인가?

원래 웹 API는 무엇을 위해 존재합니까?이런 동기 부분부터 억압한다.
웹 API의 동력은 서로 다른 시스템 간의 정보(자원)와 기능을 공유하는 데 있다.다시 말하면

시스템 A는 시스템 B의 정보를 사용하여 일부 처리

시스템 A가 시스템 B로 하여금 무엇을 하게 하는지

그래서 이것은 필요한 것이다.
예를 들어 새 서비스에 서명할 때 Google로 로그인 옵션을 사용하면 번거로운 초기 정보 로그인을 건너뛰었죠?
Google의 웹 API를 사용하여 서비스 측에서 사용자 정보를 얻고 계정 생성을 간소화한 예입니다.
API = Application Programing Interface는 말 그대로 인터페이스, 즉 연결점이므로 웹 API가 외부로부터 웹 서비스를 조작하는 데 사용되는 컨트롤러임을 미리 인식하면 된다.

가장 간단한 시스템 간 협력

그렇다면 동기는 위에서 말한 바와 같이 웹 페이지 API를 자주 접해 본 사람들에게'왜 이렇게 간단한 일을 위해 번거로운 주문을 많이 설정해야 하는가'라고 생각한다.이 의문은 초간단한 웹 API의 규격을 출발점으로 연결하기로 했다.

질문을 받으면 답장만 하는 API (http)

웹 페이지 API는 기본적으로 http를 사용하여 실현된 것이다.
http의 기본 내용을 총괄해 보겠습니다.

http 사양

우선 http(hypertext transfer protocol)는 이름과 같이 HTML과 XML 등 하이퍼텍스트를 전송하기 위한 전송 프로토콜입니다.그러나 웹 API를 통해 전달되는 json과 같은 하이퍼텍스트가 아니다. (하이퍼미디어입니까?)전달 가능합니다.good
http는 다음과 같은 정보 구성을 채택했다.이렇게'유형'이 결정되기 때문에 발송자와 수신자는 일치된 의견을 얻을 수 있을 것이다.

http의 통신은 송신정보(청구)와 회신정보(응답) 1조로 나뉜다.

서버에서 정보를 얻는 협업

서버에서 정보를 얻는 합작에서 리퀘스트 메시지에 원하는 자원 조건을 추가하여 발송합니다.
결과적으로 BODY에 포함된 요청 정보(주로 JSON 형식)에 대한 응답이 반환됩니다.

request

POST http://**** HTTP/1.1
Content-Type: application/json
Host: ****
etc: ****
↑必要なヘッダ情報

{
  "filter": {
    "key": "value",
    "key": "value",
    "key": "value"
  }
}
↑ほしい情報の細かい条件とか

response

HTTP/1.1 200 OK
DATE: ****
Content-Type: application/json
etc: ****
↑必要なヘッダ情報

{
  "key": "value",
  "key": {
    "key": "value",
    "key": "value"
  }
}
↑ほしい情報

서버 측 공동 작업 촉진

서버 측의 처리를 촉진하는 협업으로서 서버 측의 DB 데이터를 업데이트하는 처리를 쉽게 알 수 있다.
방금 처리된 것이 DB의 select라면 insert와 업데이트 등입니다.

request

POST http://**** HTTP/1.1
Content-Type: application/json
Host: ****
etc: ****
↑必要なヘッダ情報

{
  "0": {
    "key": "value",
    "key": "value",
    "key": "value"
  },
  "1": {
    "key": "value",
    "key": "value",
    "key": "value"
  }
}
↑insertするレコードの情報とか

response

HTTP/1.1 200 OK
DATE: ****
Content-Type: application/json
etc: ****
↑必要なヘッダ情報

（BODYはなかったり，書き込み情報をオウム返ししたり）

보안 문제

상술한 구조가 있다면 기능으로 충분하다.끝났어.
근데 여기 안전에 문제가 있어요.API를 누가 두드려도 처리가 실행된다는 것을 모두가 상상할 수 있을 것 같다.
자신의 Google 계정의 개인 정보를 아무나 끌어낼 수 있다면 곤란합니다.
다음에 우리는 상술한 간단한 http 웹 API가 안전 보장을 제공하는 몇 가지 메커니즘에 대해 설명할 것이다.이렇게 되면 사람들이 매일 사용하는 웹 API의 규격이 된다.

웹 API를 안전하게 사용하는 인증 방법

특정 사용자에게만 API 작업을 허용하려면 자물쇠를 채워야 합니다.웹 API에서 사용되는 열쇠의 규격은 여러 가지 변화가 있지만 다음 예에서 베어 인증, 오옥스 인증은 일반적으로 사용된다.

기본 인증

이것은 서버에 저장된 사용자 ID와 비밀번호를 조합한 정보를 열쇠로 하는 방법이다.
http 요청 헤더에

Authorization: Basic dGVzdHVzZXI6dGVzdHRlc3Q=

로 설정합니다.
여기서 Basic 뒤에 있는 문자열은 기본적으로 "ID: pass"를 인코딩한 명문입니다.
위의 예는 "testuser:testtest"문자열의 인코딩입니다.
아주 간단하게 이뤄질 수 있지만 도청 문제가 있어 약하다고 할 수밖에 없다.(Authorization의value를 기본 디코딩하면 ID/Pass를 반대로 계산할 수 있습니다)

Digest 인증

Digest 인증은 Basic 인증의 발전 버전입니다.
http 요청 헤더에

Authorization: Digest username="ユーザーID",
		nounce="ランダム文字列",
		response="パスワードとnounceをつなげてハッシュ関数に通した文字列"

로 설정합니다.
도청을 당하더라도response흩어져 있다가 당했기 때문에 비밀번호를 거꾸로 계산하는 것은 사실상 불가능한 점에서 Basic인증보다 조금 안전하다.하지만 여전히 약하다.

베어 인증

Bearer 인증은 서버에서 발행한 방문 영패를 열쇠로 하는 방법입니다.
마지막 OAuth 인증 기준의 일부분은 이것이라도 단독으로 사용할 수 있다.
http 요청 헤더에

Authorization: Bearer アクセストークン

로 설정합니다.
방문 영패는 반드시 사전에 서버에서 보내야 하고 클라이언트는 반드시 알아야 한다.어떤 발행 수단이든지 성립될 수 있다.
(예를 들어 서버에 접속 영패를 발행하는 페이지가 있고 클라이언트의 조작을 통해 새로운 접속 영패를 보내는 등)

각 접속 토큰에 대한 조작 권한 등급 설정

접속 영패에 유효기간 설정

등 방법으로 누설에 대한 피해를 최소화할 수 있다.

OAuth 인증

베어 인증에서 방문 영패의 요청부터 응답까지 모두 귀일화된 규격화된 것이 OAuth 인증이 된다.

토큰 발행을 담당하는 인가 서버가 등장했다.

클라이언트(자원 서버의 데이터를 사용하려는 시스템)에서 권한 수여 서버에 영패 요청

권한 수여 서버에서 자원 소유자(≈사용자)에게 영패 발행 확인

사용자가 자원 서버의 계정 권한 수여 영패를 통해 발행

공인 서버에서 클라이언트에 대한 액세스 토큰

토큰을 사용하여 Bearer 인증 API 닫기

이상