REST API

7091 ワード
REST API テキストリンク

読む前に..。


Restfulとは何かを検索していたところ、RestAPIに関する良い動画を見たので、まずRestAPIを勉強したいと思い、この文章を書きました.
次の文章はビデオに基づいて書かれています.
https://www.youtube.com/watch?v=RP_f5dMoHFc
REST API
RESTの略称は
問:どのようにネット上で情報を共有しますか?
A:ハイパーテキストへのリンク
  • HTML:表示情報、
  • URL:識別情報と
  • HTTP:情報を伝送するためのHTTPプロトコル
    • を作成する.
    では、HTTPを修復すればWebが崩壊するという悩み
    HTTPオブジェクトモデルの後にRESTが発行されます.
    REST API
  • RESTアーキテクチャスタイルに従うAPI
    • REST
  • 分散型スーパーメディアシステム(ex:Web)のアーキテクチャ様式
    • アーキテクチャスタイル
  • 制約の集合
    • すべての制約条件に従ってこそ、RESTを遵守することができる.
    では、RESTを構成するスタイルは、次のとおりです.
  • client-server
  • stateless
  • cache
  • uniform interface
  • layered system
  • code-on-demand (optional)
    • 現在では、HTTPにうまく従うだけで、大まかに従うことができます(クライアント-サーバ、ステータスなし、キャッシュ、階層化システム).
    code-on-demand(オプション)の場合、サーバはコードをクライアントに送信して実行し、code-on-demandになる必要があります.
    しかし、1つの統合インタフェースだけでは満足できません.

    uniform interface


    統合インタフェースの制約は4種類あります.
  • identification of resources
  • リソース識別uriでよい.
  • manipulation of resources through representations
  • リソースの作成または削除は、httpメッセージにプレゼンテーションを追加して伝送することによって実現される.
    • 例外はほとんどなく、以下の2つの条件は守られていません.

  • self-descriptive messages

  • 情報は自分を説明しなければならない.
    GET / HTTP/1.1
  • このHTTP要求メッセージは宛先がなく、自己記述できない.
    • GET / HTTP/1.1
HOST: www.example.org
  • 宛先を追加すると、
    • を自己記述できるようになりました.
    HTTP/1.1 200 OK
[ { "op" : "remove", "path": "/a/b/c" }]
  • 位の事項がどのような文法で書かれているのか分からないので説明できません.
    • HTTP/1.1 200 OK
Content-Type: application/json
[ { "op" : "remove", "path": "/a/b/c" }]
  • Content-Typeヘッダを含める必要があります.jsonを見れば説明できます.しかしopは何ですか?pathは何ですか?
    • HTTP/1.1 200 OK
Content-Type: application/json-patch+json
[ { "op" : "remove", "path": "/a/b/c" }]
  • これで完璧になります.

  • メッセージの内容として完全に解釈できるはずです.

  • hypermedia as the engine of application state (HATEOAS)
    アプリケーションのステータスはHyperlinkで移行する必要があります.
    HTTP/1.1 200 OK
Content-Type: text/html

<html>
<head></head>
<body><a href="/test">test</a></body>
</html>
    HTMLであればHATEOASを満たし、aタグでHyperlinkが現れ、Hyperlinkで次の状態に移行するので満足です.

    • なぜ統合インタフェースが必要なのか


    独立進化
  • サーバとクライアントはそれぞれ独立して進化した.
  • サーバの機能が変更されても(新しいAPIの追加、既存のAPIの変更、URIの削除など)、クライアントは更新する必要があり、X
    • .
  • RESTを作成する契機
    • 実際、REST遵守の事例はWeb
    上の内容を聞いて考えたら、どういう意味か分かりました.特定のページで変化したブラウザを更新していないからです.
    相互運用性への関心
    結論:本当に起きられない人がたくさんいます.
    REST APIはRESTのすべての制約条件を遵守すべきですか?
    リソースのAPIには、ハイパーテキストの自己記述メッセージを含む統合インタフェースを介してアクセスします.
    あなたに守らせるという意味です.

    APIはなぜRESTをサポートしないのですか?


    一般的なWebページHHTP API HTTP通信者-マシン-マシンメディアタイプHTML JSON(マシンは理解できる)
    それはJSONのせいですか??
    HTML、JSON比較
    未定義のHTML JSOnHyperlink(Aタグなど)自己記述(HTML説明)不完全*
    欠けている
  • 少なくとも文法は定義されている.
  • ですが、値は定義されていません.
    • 構文解釈は可能であるが,解釈の意味には別の文書(API文書など)が必要である.
    HTML
    GET /todos HTTP/1.1
HOST: example.org

HTTP/1.1 200 OK
Content-Type: text/html

<html>
<body>
<a href="https://todos/1" 회사 가기 </a>
<a href="https://todos/2" 집에 가기 </a>
</body>
</html>
    Self-descriptive
  • コンテンツ-タイプはtext/html、メディアタイプはtext/htmlです.
  • HTTPリストでは、メディアタイプがIANAに登録されているため、IANAはtext/htmlの説明を検索し、
    • .
  • IANAにおいて、text/html詳細はhttp://www.w3.org/TR/htmlに移動し、詳細を説明する.
  • リストには、すべてのタグの解釈方法が具体的に記載されている.
    • HATEOAS
  • aタグで表されるリンクは、以下の状態に移行することができる.
    • JSON
    GET /todos HTTP/1.1
HOST: example.org

HTTP/1.1 200 OK
Content-Type: application/json

[
	{"id": 1, "title" : "회사 가기"},
	{"id": 2, "title" : "집에 가기"}
]
    Self-descriptive
  • コンテンツ-タイプはアプリケーション/jsonなので、メディアタイプアプリケーション/jsonを確認できます.
  • IANAでアプリケーション/jsonの説明を検索すると、
    • が見つかります.
  • アプリケーション/json詳細はdraft-ietf-jsonbis-rfc 7159 bis-04です.詳細にアクセスし、
    • を解析してください.
  • リストでjsonドキュメントをどのようにパーティション化するかが指定されているため、パーティション化に成功したが、「id」が何を意味するか、「title」が何を意味するか、X->FAIL
    • をどのように知るか、
    HATEOAS
  • 次の状態へのリンクがありません->FAIL

    • では、上記の2つの制約条件はどのように独立進化に役立つのでしょうか。


    Self-descriptive
    拡張可能な通信を可能にする.
  • サーバが変化したり、クライアントが変化したりしても、メッセージは常にメッセージによってのみ解釈されます.
    • HATEOAS
    アプリケーション状態遷移のlate binding
    これは、
  • リンクを任意に変更できることを意味します.

    • n/a.結論


    本当に素晴らしいビデオでした発表を聞いた時に順番によく理解してくれました一度だけ聴いても理解できますが、また触れたい映像のようです.
    まず今日、REST APIについての内容を知りましたので、簡単にSpringプロジェクトにします.
    vueCli導入Cesium
    ブックマークレット：Udemy講座の目次を作成する