HTTP headers for the responsible developer
This article is a written version of the talk “HTTP headers for the responsible developer”. You can check the slides or the recording. Being online is the default state for many people these days. We all spend our time shopping, chatting, reading articles, and looking for information like directions. The web connects us with the whole world, but most certainly the web connects people. I myself hav
Examples of HTTP API Rate Limiting HTTP Response headers
Here are some examples of HTTP API Rate Limiting HTTP Response headers. Taken from four common REST APIs: Github, Vimeo, Twitter and Imgur: Github Rate Limiting http://developer.github.com/v3/#rate-limiting #=============================#=============================================# # HTTP Header # Description # #=============================#=============================================# | X-Rat
How I write Go HTTP services after seven years
UPDATE: You can watch a video of me giving this talk at Gophercon 2019:
ngrok - secure introspectable tunnels to localhost
🤯 Support for Kubernetes Gateway API is now available in developer preview. Learn more ->
HerokuのAPIデザイン
Herokuが自ら実践しているAPIデザインガイドをGithubに公開した． “HTTP API Design Guide” このガイドは些細なデザイン上の議論を避けて，ビジネスロジックに集中すること目的としている．Heroku特有なものではなく，一般にも十分適用できる知見となっている． 最近は，モバイル向けにAPIをつくることも多いため，勉強もかねて抄訳した．なお内容は，HTTP+JSONのAPIについて基本的な知識があることが前提となっている． 適切なステータスコードを返す それぞれのレスポンスは適切なHTTPステータスコード返すこと．例えば，“成功"を示すステータスコードは以下に従う． 200: GETやDELETE，PATCHリクエストが成功し，同時に処理が完了した場合 201: POSTリクエストが成功し，同時に処理が完了した場合 202: POSTやDELETE，PATCHリク
HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD
HTTPステータスコードを返すというのはとても単純なことです。ページがレンダリングできた？よし、それなら 200 を返しましょう。ページが存在しない？それなら 404 です。他のページにユーザをリダイレクトしたい？ 302 、あるいは 301 かもしれません。 I like to imagine that HTTP status codes are like CB 10 codes. "Breaker breaker, this is White Chocolate Thunder. We've got a 200 OK here." — Aaron Patterson (@tenderlove) 2015, 10月 7 訳：HTTPのステータスコードのことは、市民ラジオの10コードみたいなものだと考えるのが好きです。「ブレーカー、ブレーカー、こちらホワイト・チョコレート・サンダー。200
HTTPが16年ぶり大幅アップデートで「HTTP/2」へ、知っておくべきポイントは？
By ntr23 ウェブブラウザがサーバーと通信する際の方法を定めた通信プロトコルが「HTTP(Hypertext Transfer Protocol)」です。現在使用されている「HTTP/1.1」は1999年に規定されたもので、それから16年が経過した2015年になってようやく新しいバージョンの「HTTP/2」の仕様が、インターネット標準規格の最終技術レビューを行う「Internet Engineering Steering Group(IESG)」により承認されたことが明らかとなりました。 mnot’s blog: HTTP/2 is Done https://www.mnot.net/blog/2015/02/18/http2 The Largest Update to HTTP in 16 Years Has Been Finalized http://thenextweb.com
クロスサイトリクエストフォージェリ - Wikipedia
クロスサイトリクエストフォージェリ (cross-site request forgery) は、Webアプリケーションの脆弱性の一つ[1]もしくはそれを利用した攻撃。略称はCSRF（シーサーフ (sea-surf) と読まれる事もある[2][3]）、またはXSRF。リクエスト強要[4]、セッションライディング (session riding[3]) とも呼ばれる。1990年代はイメタグ攻撃とも呼ばれていた[要出典]。脆弱性をツリー型に分類するCWEではCSRFをデータ認証の不十分な検証 (CWE-345) による脆弱性のひとつとして分類している (CWE-352)[5]。 なおCSRFの正式名称はクロスサイトスクリプティング (XSS) と似ているが、XSSは不適切な入力確認 (CWE-20) によるインジェクション (CWE-74) のひとつとして分類されており[5]、全く異なる種類の
なぜ html の form は PUT / DELETE をサポートしないのか？ - Block Rockin’ Codes
注意 内容については一切保証しません。 ここでは、主に W3C ML での議論や各種仕様などに基づいて書いています。 ここに書かれていることが正しいかどうかは、自身で判断して下さい。 事実としておかしいところなどは、コメントでどんどん指摘して下さい。遠慮はいりません。 ただし、このエントリでは「form が PUT/DELETE をサポートするべきかどうか？」の議論はしません。 「REST の是非」や「PUT/DELETE の意義」についても議論する気はありません。 ここでやっているのは、あくまでもどういった議論の末現状があるのかの調査です。 そうした意見がある場合は、 W3C などに投稿するのが最も有益だと思います。 History 2014/03/29: 公開 2014/03/29: XForm と XHTML の関係を明確化(thanx koichik) 2014/03/29: HT
GETとPOSTの使い分け - フォームデータの送信 -- ごく簡単なHTMLの説明
ブラウザからのデータデータは、特別な形式でエンコードされて送信されることになっています。画面に表示されるフォームのコントロールで入力する以外にも、隠されたデータの情報を送ったり、フォームを使わずに送信するなど、いくつかの方法があります。 目次： 作者の設定したデータを送る データ送信とURLエンコード フォームから直接メール送信 エンコードのタイプとファイル送信 GETメソッドとPOSTメソッド GETを使って直接データを送る 作者の設定したデータを送る input要素などで用意する「コントロール」はユーザーがそれを操作してデータを入力するためのものです。しかし、場合によってはHTMLの制作者が指定したデータをプログラムに送信したい場合もあるでしょう。このようなデータはユーザーが操作する必要はなく、ユーザーの目に触れないほうが都合がよいものです。そのために、input要素のタイプの一つとし
yohei-y:weblog: REST 入門(その5) 四つの動詞 -- GET, POST, PUT, DELETE
» REST 入門 目次 前回、URI で特定できるリソースに HTTP の GET という動詞を適用して、 ある時点・条件での状態の表現を転送するのが REST だという説明をしました。 URI (名詞)に適用できる動詞は GET だけではありません。 今回は GET 以外の三つの動詞を紹介します。 前提知識 ここでは実際に稼動している REST 実装の例としてはてなブックマーク AtomAPI を使います。 はてなブックマークそのものの説明はしませんので、あらかじめご了承ください。 はてなブックマークに登録したひとつのブックマークを考えてみてください。 このひとつのブックマークエントリが、対象のリソースになります。 たとえば REST 入門の目次をブックマークしたとします。 このブックマークの URI は http://b.hatena.ne.jp/atom/edit/175062 で
RESTとは - IT用語辞典
概要 REST（Representational State Transfer）とは、分散システムにおいて複数のソフトウェアを連携させるのに適した設計原則の一つ。2000年にロイ・フィールディング（Roy Fielding）氏が提唱した。狭義には、それをWebシステムに適用したソフトウェアの設計様式を指し、一般にはこの意味で用いられることがほとんどである。 一般によく使われる（本来は狭義の）RESTは、パラメータを指定して特定のURLにHTTPでアクセスすると、XMLやJSONなどで記述されたメッセージが送られてくるようなシステム、および、そのような呼び出し規約（「RESTful API」と呼ばれる）のことを指す。 システムやセッションの状態に依存せず、同じURLやパラメータの組み合わせからは常に同じ結果が返されることが期待される。ただし、厳密な技術的定義が共有されているわけではなく、「S
【Web全般】GET メソッドと POST メソッドの違い（簡易全体像）
今回はGETメソッドとPOSTメソッドの違いについて。 Webで普通に使ってきていたGETメソッドと、POSTメソッドの違いについて勉強したのでそのメモです。 こういった基礎的な部分をしっかり勉強していくことで、応用につなげていきたい！ 🐹 HTTPリクエストについてHTTPリクエストは、大きく3つの部分に分かれる。 1) HTTPリクエスト行 2) HTTPヘッダー行 3) HTTPリクエストのボディ部 🚜 GETメソッドについて* リクエストURLの後にパラメータを付与してデータを送付する * データを取得するときに使用する。副作用がない、常に結果が同じになるような処理に用いる * URLの文字数は、IEでの制限があり2048文字 🗽 POSTメソッドについて* HTTPリクエストのbody部にパラメータ(データ)が含まれる * テキストデータでもバイナリデータでも送信できる
CORS(Cross-Origin Resource Sharing)について整理してみた | DevelopersIO
ブラウザからAmazon S3に直接ファイルをアップロードしたい 先日、Amazon S3にファイルをアップロードするWebアプリを作ろうとして色々調べていたところ、S3にCORSという仕様のクロスドメインアクセスの設定をすることによって、ブラウザから直接S3にアップロードをする方法にたどり着きました。ただ、この方法を使うにあたってはCORSというクロスドメインアクセスの仕様をきちんと理解しておいた方が良さそうでしたので、まずはCORSについて自分なりに整理してみました。 なお、弊社の横田がCORSとS3についての記事を以前書いていますので、S3のCORSサポートに関する概要を知りたい方はそちらをご覧下さい。 CORS(Cross-Origin Resource Sharing)によるクロスドメイン通信の傾向と対策 CORS ブラウザでAjax通信を行う際には、同一生成元ポリシー(Same
オリジン間リソース共有 (CORS) - HTTP | MDN
HTTP ガイド リソースと URI ウェブ上のリソースの識別 データ URL MIME タイプ入門 よくある MIME タイプ www 付きと www なしの URL の選択 HTTP ガイド HTTP の基本 HTTP の概要 HTTP の進化 HTTP メッセージ 典型的な HTTP セッション HTTP/1.x のコネクション管理 プロトコルのアップグレードの仕組み HTTP セキュリティ Content Security Policy (CSP) HTTP Strict Transport Security (HSTS) X-Content-Type-Options X-Frame-Options X-XSS-Protection Mozilla web security guidelines Mozilla Observatory HTTP アクセス制御 (CORS) HTTP
JSON on HTTPやWeb APIを各言語でどうやって実装するのか
HTTPでアクセスして、JSONを返すようなWebサーバを書きたいとする。 どんな言語を選ぶか。どんなミドルウェアを選ぶか。どんなライブラリを選ぶか。 たとえば、TIOBE Softwareが公表している「Programming Community Index(PCI)」という指標がある。人気のあるプログラミング言語の数値化。これを見ていて思ったのは、「多すぎだよね、プログラミング言語」ということ。これらのうち、どの言語を勉強し、どの言語をプロジェクトに採用すべきなのか。 その感触を得るために、 「同じ仕様のREST serviceを複数言語で実装したらいいんじゃね？」 と思った。いくつかの言語で実装を起こしてみている。 前提条件 大規模な開発を想定する。ユーザの規模が大規模。トランザクション数が大規模。そして、開発者が大規模。 実用的かつモダンな開発を想定する。プロジェクト毎のバージョン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HTTP and 5G (fixed1)
「HTTP/2」がついに登場！ 開発者が知っておきたい通信の仕組み・新機能・導入方法
IBM Developer
300 Multiple Choices - HTTP Status Code