HTTP API


HTTP APIの作成方法


1.URIの作成時に「リソース」を理解する.
  • 「ユーザークエリー」/read-user
  • 「ユーザー登録」/regist-user
  • 「ユーザーの変更」/update-user
  • 「ユーザーの削除」/delete-user
    例えば、上記4つのAPIが存在する場合、「リソース」は「ユーザ」となる.
  • 2.方法は「行為」を指す.
    クエリー、登録、修正、削除などの動詞をGET、POST、PUT、PATCH、DELETEなどの方法に変換することができます.

  • 一般的な方法
  • GET-主に単純クエリーまたはフィルタクエリーに使用されます.
  • POST-主に登録に使用されますが、他の用途にも使用できます.
  • PUT-は、値を置換し、既存の値を上書きするために使用されるため、注意が必要です.
  • PATCH-値の一部を置換します.
  • DELETE-名前で値を削除します.

  • その他の方法
  • HEAD-GETは応答主体を返さず、ステータスラインとタイトルのみを返す
  • OPTIONS-ターゲットリソースのオプション通信方法を説明
  • CONNECT-ターゲットリソース識別のサーバにトンネルを設置
  • TRACE-メッセージフォールバックテストをターゲットリソースのパスに沿って実行
  • 3.制御URI
    リソースやメソッドでURIを記述できない場合、制御URIと呼ばれる動詞として登録する必要がある場合がある
    http://api.example.com/cart-management/users/{id}/cart/**checkout**
    http://api.example.com/song-management/users/{id}/playlist/**play**
    上のチェックアウトとプレイはコントロールURIに対応しています

    メソッドの特性



    -セキュリティ(Safe):既存の値には影響しません
    -べき乗等性(Idempotent):複数回のリクエスト後、結果値は1回のリクエスト後も変わらない.これには、リソースのリカバリなどの利点があります.
    ex) DELETE/user/1
    DELETE/user/1-->は削除されているため、再削除できません
    また,再リクエスト中に他の場所でリソースを変更するなどのことは考えられない.
    ex) GET/user/1
    PUT /user/1
    GET/user/1
    -キャッシュ可能応答結果をサーバにキャッシュする場合、実際の操作はGETのみを使用し、他の方法では実行しにくいため、使用しにくい.

    クライアントからサーバへのデータ転送


    2つのデータ転送方式があります。


    1.クエリー・パラメータによるデータ転送
  • GET(主にソートフィルタ)
  • 2.メッセージ本体によるデータ転送
  • POST、PUT、PATCH(会員入力、商品注文、資源登録、資源変更等)
  • クライアント->サーバへのデータ転送の4つのシナリオ


    1.静的データ照会
    テキスト、画像ファイルなどを静的に照会する場合は、リソースパスでのみ処理し、GETを使用することができます.
    2.動的データ照会
    クエリー・パラメータを使用してデータを動的にクエリーします.主にフィルタなどを用いてクエリーを行い,GETを用いる.
    3.HTML Formデータ転送
    (未使用の転送方法)HTMLソースのみを使用して転送します.actionやmethodなどを定義して使用できます.GETとPOSTのみ利用可能
    <form action="/user" method="get">
      <input name="username">
      <input name="age">
      <button type="submit">
    Content-type defaultはx-www-form-urlencodedクエリーパラメータのようにkey、valueとして作成しbodyで作成します.
    転送データをurl符号化処理する.
    ファイルを転送する場合は、formラベル内でenctype="multipart/form-data"プロパティを使用します.
    4.HTTP APIデータ転送
    サーバ-サーババックエンドシステム通信、アプリケーションクライアント、Webクライアント(Ajax)Content-type主にアプリケーション/jsonを使用

    HTTP API設計例


    1.POSTベースの登録例

    • 회원 목록 /members -> GET
    • 회원 등록 /members -> POST
    • 회원 조회 /members/{id} -> GET 
    • 회원 수정 /members/{id} -> PATCH, PUT, POST
    • 회원 삭제 /members/{id} -> DELETE
    -クライアントは登録するリソースのURIを知らない.
  • ex)登録会員/member->POST
  • -サーバは、新しく登録されたリソースURIを生成します.
  • HTTP/1.1 201 Created
    Location:/members/100
  • -集合
  • サーバ管理のリソースディレクトリ
  • サーバがリソースを作成および管理するURI
  • members
  • 2.PUTベースの登録例(ファイル管理システム)**

    • 파일 목록 /files -> GET
    • 파일 조회 /files/{filename} -> GET
    • 파일 등록 /files/{filename} -> PUT
    • 파일 삭제 /files/{filename} -> DELETE
    • 파일 대량 등록 /files -> POST
    ->プロジェクトのイメージ登録セクションをPUTに置き換える必要がある場合があります
    -クライアントはリソースURIを知る必要があります
  • ファイル登録/files/{filename}->PUT
  • PUT/files/start.jpg
  • -クライアントは、リソースのURIを直接指定します.
    -ストア(Store)
  • クライアントが管理するリソースストレージ
  • クライアントがリソースを理解して管理するURI
  • ここの店は/files
  • 3.HTML FORM**の使用

    • 회원 목록 /members -> GET
    • 회원 등록 폼 /members/new -> GET
    • 회원 등록 /members/new, /members -> POST
     * 등록 폼 -> 등록으로 가는 URI(/new까지)는 대체로 맞춰주는 편이 좋다(리다이렉션 등을 고려해서)
    
    • 회원 조회 /members/{id} -> GET
    • 회원 수정 폼 /members/{id}/edit -> GET
    • 회원 수정 /members/{id}/edit, /members/{id} -> POST
    • 회원 삭제 /members/{id}/delete(컨트롤 URI) -> POST
  • HTML FORMはGET、POST
  • のみサポート
  • AJAXなどの技術を用いて問題を解決
  • コントロールURI
    •ドキュメント、コレクション、ショップを使用して、他の困難なプロセスを実行します.
    ドキュメント、コレクション、ショップとは何かを混同している場合は、もう一度スクロールして参照してください.
    •GET、POSTのみ対応のため、制限があります
    •これらの制限を解決するために動詞のリソースパスを使用する
    •POST上の/new、/edit、/deleteは制御URI
    •HTTP手法による不明確な問題の解決(HTTP APIを含む)
  • 最後のアレンジ
  • 鉱物を掘る(資源!!)
  • 行為を指定する方法
  • 正!ダメならコントロールURIを書きます.
  • Reference

  • https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard
  • https://restfulapi.net/resource-naming/
  • https://girawhale.tistory.com/66
  • https://velog.io/@annmj/API-URI-%EC%84%A4%EA%B3%84-%EB%B0%A9%EB%B2%95%EA%B3%BC-HTTP-%EB%A9%94%EC%84%9C%EB%93%9C-%EC%A0%95%EB%A6%AC