そんなREST APIでいいですか?

7691 ワード
REST API テキストリンク
この記事は、DEVIEW 2017「そんなREST APIでいいですか」の講演を見てまとめたものです.リンクは下に残ります.

1.RESTの誕生背景


1991年にWEBが登場し、インターネット上で情報を共有するためにHTML、URI、HTTPが誕生した.HTTP開発プロセスに参加したLoyFeelding氏は「How doIはWebを破壊することなくHTTPを改善するのか」と述べた.悩んだあげく、ついにRESTを発表した.

どうやって有名になったの?


APIのインターネットへの導入に伴い、1998年にマイクロソフトが発表したSOAPプロトコルが最も早く主流となった.
2000年SalesforceはSOAPを用いてAPIを公開した.
4年後、FlickrもAPIを発表し、SOAPとRESTを利用した.
SOAPバージョン
RESTバージョン
これを見て、RESTは簡単で、ルールが少なく、簡単だと思っていたが、その後、RESTの人気は直線的に上昇した.

3.REST APIじゃないの?


2016年にマイクロソフトはREST APIガイドを発表した(その内容は私たちが考えているREST APIと同じであることが多い).しかし、RESTを作ったロイ・フィルディンはそれを見て、それはRESTではないと言った.

REST APIとは?


RESTアーキテクチャスタイルに従うAPIは一言で定義できます.
この場合、アーキテクチャスタイルは制約条件の集合であり、アーキテクチャスタイルを遵守するには、集合内のすべての制約条件を遵守する必要があります.
RESTには、次の6つのアーキテクチャスタイルがあります.
  • Client - Server
  • stateless
  • cache
  • layered system
  • uniform interface
  • code on demand (optional)
    • 実際、1~4番HTTP APIを使っても守られる問題です.問題は、通常REST APIと呼ばれる多くのAPIがUniformインタフェースを遵守していないことである.
    Uniform interfaceには、次の4つの制約があります.
  • identification of resouces
  • manipulation of resource through representations
  • self-descriptive messages
  • HATEOAS
    • RESTと呼ばれるAPIのほとんどは,3,4番制約を遵守できなかった.

    5. Self-descriptive message


    ではself-記述的な情報とは何でしょうか.
    以下の例で説明します.
    GET / HTTP/1.1
    説明できませんどこから受け取ったのか分からないので.
    GET / HTTP/1.1
HOST: www.google.com
    自己記述.
    このような情報だけで説明できるものをself-記述性と呼ぶ.
    別の例を見てみましょう.
    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"}]
    上記の例よりも記述的であるがself-descriptionではない.op、パスの意味が分からないから.
    HTTP/1.1 200 OK
Content-Type: application/json-patch+json

[{ "op": "remove", "path": "/a/b/c"}]
    これがself-の説明です.(json-patchはmedia-typeリストだと思います)
    明確なリストがあるので、ニュースを見た人はそのニュースを把握することができます.

    6. HATEAOS


    HATEAOSは「Hyperlink経由でアプリケーションの状態を移行する必要がある」
    HTTP/1.1 200 OK
Content-Type: text/html

<html>
<head></head>
<body><a href="/test">test</a></body>
</html>
    ハイパーリンクによってアプリケーションの状態が遷移する可能性があるため、HATEAOSの要件を満たします.

    7. Why Uniform Interface


    なぜ、このような厳しいSelf-DescriptionおよびHATEAOS制約を満たすために、統合されたインタフェースアーキテクチャスタイルを使用するのですか?
    独立して進化できるからだ.
    自己記述すると、サーバやクラウドが変更されてもメッセージとして解釈できるので問題ありません.
    HATEAOSではリンクを動的に変更できるため、サーバが変更されてもクライアントは変更する必要はありません.
    最終的には、サーバクライアントは独立して進化し、サーバの機能が変化してもクライアントを更新する必要はありません.
    RESTを作成したきっかけは「How doIがWebを破壊することなくHTTPを改善すること?」一脈相承.

    8.RESTをきちんと守っていますか？


    ネットワークです.
    웹 페이지를 변경했다고 웹 브라우저를 업데이트 할 필요는 없다.
웹 브라우저를 업데이트했다고 웹 페이지를 변경할 필요도 없다.
HTTP 명세가 변경되어도 웹은 잘 동작한다.
HTML 명세가 변경되어도 웹은 잘 동작한다.

    9.なぜ普通のAPIがうまく回復できないのか。


    REST準拠のWebとの比較
    HTTP APIと一般的なウェブページの最大の違いはメディアタイプ(JSON v.s HTML)
    HTML自体には明細があり、ハイパーリンクを表すタグもあります.
    GET /todos HTTP/1.1
HOST: example.org

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

<html>
<body>
    <a href="https://~~~~>todo1</a>
    <a href="https://~~~~>todo2</a>
</html>
    上記情報があれば、
  • 応答メッセージのコンテンツタイプを表示し、メディアタイプがtext/html
    • であることを確認する.
  • httpリストは、メディアタイプがIANAに登録されていることを示す
    • .
  • 人を見つけることができ、彼らのリストには説明ラベルの方法が書かれています.
    従ってself-descriptionはaタグによって次の状態に移行できるのでHATEOASを満たす.
    • では、一般的なHTTP API応答コードを見てみましょう.
    GET /todos HTTP/1.1
Host: example.org

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

[
	{"id":1, "title": "todo1"},
	{"id":2, "title": "todo2"},
]
    同様にJSONの明細を見つけてグループ化することができるが、その中の「id」が何なのか、「title」が何を意味するのか、リンクもないのでself-descriptionもHATEOASも満足できない.

    RESTのように直しましょう!


    まず自己説明を満たしましょう


    1つ目の方法はMedia typeを指定することです.メディアタイプを定義し、IANAに登録し、Content-typeに明記します.
    2つ目の方法はhttpリンクリーダーを使用することです.具体的には、「id」と「title」とは何かのリストを記入した後、
    HTTP ~~~
Content-type: ~~~
Link: <명세의 링크>; rel="profile"
    このような形式でprofileを記録します.
    もちろん、明細を記入する必要はありません.社内で使えば、明細がなくても社内のすべての人が理解できる限りself-descriptionと見なすことができます.

    HATEAOSを満足させよう


    データにLINKを書くのも一つの方法です.
    http Link HeaderまたはLocation Headerを使用してlinkを表すこともできます.
    すなわち,dataやheaderでリンクを表すとよい.

    10.こんなに難しいREST...必ず使いますか。

    시스템 전체를 통제할 수 있다고 생각하거나, 진화에 관심이 없다면, REST에 대해 따지느라 시간을 낭비하지 마라.
    RESTは、サーバとクライアントの管理主体が互いに独立したアプリケーション環境(Webなど)に重点を置いているため、現代のサービスと一致しない可能性があります.
    対外的に公開されているAPIであれば、RESTアーキテクチャスタイルを守れば、それ自体の特性上、APIの理解が容易であり、依存性が生じないので、非常に適していると思います.
    どんな技術でも目的地があればよく使えばいい.
    ソース:https://tv.naver.com/v/2292653#comment_focus
    素晴らしいスピーチに感謝します:)
    エリキシルの日付を比較すること
    [drf]airbnb-api -11 MeView & user_detail