タグ

関連タグで絞り込む (3)

タグの絞り込みを解除

httpとapiに関するgriefworkerのブックマーク (5)

  • RESTFulなAPIとCSRFとその対策 - シアトル生活はじめました

    Cross-Site Request Forgery（クロスサイトリクエストフォジェリー）って何？ 頭文字をとって「CSRF」ですが、出来るだけ平たく説明すると 「悪いヤツが作ったサイトから読み込んだHTMLやらスクリプトが、勝手に別のサイトにHTTP POSTのリクエストを送信して、知らない間にそのサイトにある自分のデータなどを変更される」 といった感じになるかな。 データの中には重要なデータもあるでしょう。Amazonで欲しい物リストがあったとして、それが全部勝手に「購入」されたら困りますよね。銀行の口座から別の口座にお金が入金されても困ります。（もちろん、Amazonや銀行のサイトなどではCSRF対策がしっかりと施されているでしょうから、大丈夫！・・っであることを祈る） Cross-site とは二つのウェブサイトを跨いでること。サイトのひとつは当然「悪いヤツのサイト」でもうひとつは

    RESTFulなAPIとCSRFとその対策 - シアトル生活はじめました

  • Idempotency-Key Headerを使ったリトライと、オンラインイベントの"Kaigi感" - inSmartBank


    去る2021年10月23日に開催されたKaigi on Rails 2021にて、弊社の@ohbaryeが "Safe Retry with Idempotency-Key Header" というタイトルで発表してきました。 発表スライドはSpeakerDeckにて公開済みです。 後日アーカイブ動画も公開されるとのことですのでそちらも是非ご覧頂きたいのですが、おとなしく30分の動画を視聴できるほど現代人は暇じゃないですよね。なので本記事の前半では忙しい人のために発表内容を1/10ぐらいの密度で解説してみます。 (2021-10-31追記) 動画が公開されました 🎉 www.youtube.com (2021-10-31追記おわり) ただ、それだけでは配信動画をすでに視聴いただいた方への新規情報がゼロになってしまうので、後半では発表に関していただいたtweet・質問・感想へのコメントへのリ
    Idempotency-Key Headerを使ったリトライと、オンラインイベントの"Kaigi感" - inSmartBank

  • RESTful API設計におけるHTTPステータスコードの指針 - Qiita


    RESTful APIを設計した際のステータスコードの指針です。 メソッド別 GET 成功した場合 200 OK‥最も一般的 304 Not Modified‥条件付きGETでキャッシュを使わせたい場合 POST 成功した場合 201 Created 作成したリソースのURIを示すLocationヘッダを付けておく 議論 200 OKだとまずいのか？ 200 OKを応答する実装も多くあり、まずいというわけでもない 200 OKはPOST結果がキャッシュ可能、201 CreatedはPOST結果がキャッシュ不可能として分けてもいいが、そこまでする必要があるか？︵POSTのキャッシュは一般的ではない︶ 204 No Contentだとまずいのか？ クライアントがPOST結果を事前に全て知っているわけではないのでNo Contentは不親切では？ 失敗した場合 409 Conflict‥作成しよ
    RESTful API設計におけるHTTPステータスコードの指針 - Qiita

  • HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD


    HTTPステータスコードを返すというのはとても単純なことです。ページがレンダリングできた？よし、それなら 200 を返しましょう。ページが存在しない？それなら 404 です。他のページにユーザをリダイレクトしたい？ 302 、あるいは 301 かもしれません。 I like to imagine that HTTP status codes are like CB 10 codes. "Breakerbreaker, this is White Chocolate Thunder. We'vegot a 200 OK here." — Aaron Patterson (@tenderlove) 2015, 10月7訳‥HTTPのステータスコードのことは、市民ラジオの10コードみたいなものだと考えるのが好きです。﹁ブレーカー、ブレーカー、こちらホワイト・チョコレート・サンダー。200
    HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD

  • HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様


    今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための︵レスポンスボディに載せられる︶標準的な形式が、RFC7807 Problem Details for HTTP APIsで定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
    griefworker
    griefworker 2017/01/18
    RFCがあるのか。
    リンク
  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.