RESTとREST API

5644 ワード
REST テキストリンク

REST(Representational State Transfer)


RESTはRoy Fielding 2000年の論文で紹介され、Webの創始者の一人である.Webの利点,すなわちRESTを最大限に利用できるネットワークベースのアーキテクチャを紹介した.
  • 解釈:リソースを名前で区切って、そのリソースの状態と受信したすべての
    • を提供する.

    コンポーネント


    次の3つの要素はRESTのコア3つの要素です!

    자원, 조작, 표현1)リソースとは?
  • サーバ上
  • DBの各データ.
    ex)ユーザー、注文等
  • または、1つの画像を表す.number_24 , number_25ex) https://www.123rf.com/stock-photo/number_24.html
  • URIは、リソースを識別および区別するために使用される.
    • 2)操作とは?
  • Client指定リソースの操作をHTTPメソッドを使用して要求
    • 3)表現とは?
  • クライアントがサーバに送信자원에 대한 조작을 요청サーバが応答します.

    • 整理する


    RESTの具体的な概念は,HTTP URLによりクライアントとサーバ間でリソースを識別することである.
    HTTP方式(POST、GET、DELETE、PUT等)
    これは、操作を要求し、応答を得ることを意味する.

    審査の6つの基本原則


    6つの最も基本的な原則を遵守することを強調する.

    1.クライアント-サーバモード

  • クライアントロールはサーバから分離されており、独立して置換および開発できます
  • ユーザインタフェースはデータ処理領域から分離されており、メンテナンスが非常に容易である

    • 2.ステータスなし


  • セッションステータスはサーバに格納されていません.必要に応じて外部データベースに格納することもできます.

  • サーバはリクエストの送信時にのみ応答を送信し、クライアントはセッションの管理を担当します.
  • 利点:スケーリングが自由です.


    • 3.キャッシュ可能

  • RESTは、Web標準HTTPを使用するため、Webで使用される既存のインフラストラクチャを使用することができる.したがって、HTTPが持つキャッシュ機能を適用することができる.
  • HTTPプロトコルで使用されるタグは、キャッシュ処理を行うことができる.
  • キャッシュ処理は主にGET要求処理によるものである.△post、putでもいいですが、あまり使いにくいです.
  • 関連タイトル
  • If-Match
  • クライアントとともに送信されたタグ識別子と同じ値の場合、200
  • 他の値がある場合、412 httpコードを使用して応答および上書き
  • If-Modified-Since
  • Last-Modifiedの値はタグ付けされて転送され、同じコンテンツであれば(最終変更時間が同じであれば)、応答304 httpコード
  • その他のコンテンツの場合(If-Modified-Sinceのlast-Modified値の後にデータが変更された場合)、応答は200
  • If-None-match:ETag識別子と同じ値の場合、送信304;値が異なる場合、応答200.新しい値の作成と上書きの禁止
  • キャッシュ検証ヘッダ
  • ETag
  • last-modified
  • 参照
  • 412:Precondition Failed,クライアントエラー応答コードはターゲットリソースへのアクセスを拒否することを示す
  • ETag:ETag HTTP応答ヘッダは、特定のバージョンのリソースを識別する識別子である.(like身分証明書番号)

    • 4.自己表現構造

  • REST APIを参照するだけで簡単に理解できます.

    • 5.階層化された階層化システム

  • クライアントの場合、REST APIサーバのみが呼び出されます.
  • しかし、RESTサーバは複数の層にわたって構成することができ、ロードバランシングおよび暗号化層を追加することによって構造の柔軟性を提供し、PROXYおよびゲートウェイのようなネットワークベースの中間媒体を使用することができる
  • 内部層を非表示にし、隣接層のみに開示し、層間結合を低減する.

    • 6.統合コネクタ（ユニフォームコネクタ）

  • HTTP規格では、任意の言語またはプラットフォームで使用できます.
  • IOSプラットフォームは、特定の言語またはプラットフォームに依存しません.

    • REST API設計ガイドライン


    1)URIのリソース名は動詞ではなく小文字を使用する
    GET    /members/delete/1
    deleteなどの行為を表す表現は避けるべきである.
    単数名詞ではなく複数の名詞を使う
    2)資源の行為はHTTP法により表現される
    DELETE   /members/1
    意味:会員のIDが1の会員を削除する
    3)ハイフン(－)URIの可読性
    下線()は使用しません.
    4)階層関係を表すスラッシュ区切り記号(/)
    URIの最後の文字として使用できません.
    GET    /members/1/ (X)
GET    /members/1  (O)
    5)ファイル拡張子はURIに含まれない.
    コンテンツタイプは、Accept Headerを使用して通知できるので、このHeaderを使用して通知できます.

    リソース間の関係を表す


    1)所有関係を表す
    GET     /users/{userId}/devices ( 유저가 가지고 있는 디바이스 목록 )
    2)具体的な表現が必要な場合
    GET    /users/{userId}/likes/devices ( 유저가 좋아하는 디바이스 목록 )

    レスポンスメッセージの処理

    잘 설계된 API 는 리소스에 대한 응답까지도 잘 해줘야 한다.1)200台
  • 200:クライアント要求を正常に実行
  • 201:POSTリソース作成成功
    • 2)400台
  • 400:クライアント要求が無効な場合は
    • を使用します.
  • 401:認証されていないクライアント要求に対する応答
  • 403:未許可で応答したくないリソースへのアクセスを試みたときの応答
  • 405:要求リソースの無効化方法を使用する場合に使用される応答
    • 3)500台
  • 500:サーバに問題が発生した場合に使用するレスポンスコード
    • 4)300台
  • 301:応答コード

    • Reference

  • https://jaenyeong.github.io/interview/next-step-interview/#%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC
  • https://velog.io/@couchcoding/%EA%B0%9C%EB%B0%9C-%EC%B4%88%EB%B3%B4%EB%A5%BC-%EC%9C%84%ED%95%9C-RESTful-API-%EC%84%A4%EA%B3%84-%EA%B0%80%EC%9D%B4%EB%93%9C
  • https://velog.io/@gga4638/REST-REpresentational-State-Transfer
  • https://velog.io/@stampid/REST-API%EC%99%80-RESTful-API#1-rest%EB%9E%80
  • https://velog.io/@kjh107704/REST-%EC%84%9C%EB%B2%84-REST-API%EB%9E%80
  • https://velog.io/@shroad1802/REST
  • https://withbundo.blogspot.com/2017/07/http-13-http-iii-if-match-if-modified.html
  • https://developer.mozilla.org/ko/docs/Web/HTTP/Caching
  • https://sharplee7.tistory.com/49
    • [Go]変換符号化処理ページ表示文字化け
    210806