第1章 進化するHTTPの歩み ～ HTTP/1.1とHTTP/2をおさらいし、HTTP/3の基本を知る | gihyo.jp
HTTP/3入門 第1章進化するHTTPの歩み ～ HTTP/1.1とHTTP/2をおさらいし、HTTP/3の基本を知る この特集記事は2021年6月24日に発売されたWEB+DB PRESS Vol.123に掲載された特集1「HTTP/3入門」を再掲したものです。 先日2022年6月にHTTP/3を含むHTTP関連の仕様が正式なRFCとなりました。ここではRFCの正式リリースに伴い、いち早く変更点を抑え、囲みボックスを用いた加筆解説でわかりやすくお伝えしております。 特集のはじめに HTTP（Hypertext Transfer Protocol）の最新版であるHTTP/3が登場しました。HTTP/3では、より安全で速い通信が行えます。本特集では、今までのHTTPにあった課題と、HTTP/3で課題をどのように解決し、改善が行われたかを解説します。 本章では、HTTPそのものと各バージ
Goのおすすめのフレームワークはnet/http | フューチャー技術ブログ
僕としてはGoのおすすめのフレームワークを聞かれたら、標準ライブラリのnet/httpと答えるようにしています。というよりも、Goの他のフレームワークと呼ばれているものは、このnet/httpのラッパーでしかないからです。 Goでアプリケーションを作成する場合のイメージは次の通り。battery includedなアプローチは他の言語でもたまにありますが、ついてくる機能が今時のものが多くて、標準ライブラリで済むことが多いです。ウェブ開発についてもそんな感じです。 PythonとかRubyとかもそうですが、言語組み込みのウェブサーバー機能はテスト用で本番運用には機能が足りない、性能が足りない、ということから「プロダクションに耐えうるフレームワークを別に入れないと」と思う人も多いんじゃないかな、と思いますが、Goの場合は組み込みのサーバーで問題なかったりします。Node.jsに近いかも？世間に
HTTP クライアントを作ろうとして学ぶ、使いやすいインタフェース / #GoCon_Sendai 2020
Go Conference 20' Autumn SENDAI - https://www.youtube.com/watch?v=7SdxaKurDOc - How to design a good API and why it matters https://research.google/pubs/pub32713/ - gRPC の話 https://speakerdeck.com/south37/real-world-migration-from-http-to-grpc-in-ruby-number-grpcconf - https://github.com/izumin5210/hx
本当に使ってよかったOpenAPI (Swagger) ツール | フューチャー技術ブログ
サードパーティ製のツール本家からは上述のツールが提供されていますが、サードバーティ製の様々なツールが世の中には存在します。 エコシステムが成熟しているのもSwaggerを利用するメリットの一つですね。 https://openapi.tools/ 冒頭のとおり、このサードパーティ製のツールの中で実際に利用して良かったツールを3つご紹介したいと思います。 Stoplight Studiohttps://stoplight.io/studio/ 1つ目のツールは「Stoplight Studio」というAPI仕様を記載するためのGUIエディタとなります。 今までSwagger Editorを利用してYAMLを書いていたそこのみなさん、YAML筋力はもう必要ありません。 Design APIs 10x faster の謳い文句どおり、Stoplight Studioを使えばGUIで直感的に、高速
新しいプログラミング言語の学び方 HTTPサーバーを作って学ぶ Java, Scala, Clojure
JJUG CCC 2017 Fallでの発表資料です。
あの人気サービスは、Webサイトを高速化するために何をしているか | Wantedly Engineer Blog
最近、Webサイトの高速化が話題になっています。 Wantedlyでもサーバーサイドのレスポンス速度はしっかりトラッキングして取り組んでいましたが、フロントエンドはまだまだやれることがあると認識し、悔しさを胸にさっそく動き出しています。 取り組むに当たって、まずは事例を集めていくことから始めました。サーバーサイドの実装を見ることはできないですが、フロントエンドは頑張れば覗けるので、Webサイトの高速化に取り組んでいそうな他のサービスをじっくり観察することで、自分たちのプロダクトに最適な方法を選択できるはずです。 様々な種類のサービスを提供しているサイトを調査してみると、その高速化の手法はサービスごとに結構違っていて、学ぶことが想像以上に多かったので、ブログにまとめてました。同じようにWeb高速化へのモチベーションが高まっている皆さんの参考になれば幸いです。 Netflixまずは、動画ストリ
Prevent unnecessary network requests with the HTTP Cache | Articles | web.dev
Prevent unnecessary network requests with the HTTP Cache Stay organized with collections Save and categorize content based on your preferences. Fetching resources over the network is both slow and expensive: Large responses require many roundtrips between the browser and the server. Your page won't load until all of its critical resources have downloaded completely. If a person is accessing your s
ウェブページを1秒台で表示させる原理と方法 | Philosophy Guides
可能な限り最新の情報を反映していますが、追いつけていないこともあります。本サイトに採用していても、記事に反映できていない設定もあります。ページのソースを読んでいただくと、参考になる箇所があるかもしれません。 ウェブページの高速化に関するテクニックは、ネットで検索すれば簡単に見つけることができます。優れた情報も数多くありますが、｢CSSとJavaScriptはminify（ミニファイ）しておけばOK！」のような都市伝説も少なくありません。 そこで、ここでは本サイトのデザインリニューアル時に施した対策をもとに、一歩進んだウェブページの高速化の方法と、それを支える原理について、できる限り分かりやすく説明したいと思います。フロントエンジニアやデザイナーの方からすれば「んなもん知っとるわ！」な情報なのかもしれませんが、都市伝説を駆逐すべく、私なりの仕方で解説（≒加勢）したいと思います。 初めに結果を
MPEG-DASHによるリニア型配信 / Linear broadcasting by MPEG-DASH on AbemaTV
2017/10/22 AbemaTV Developer Conference 2017 http://developer.abema.io/2017/ ・MPEG-DASHの基礎 ・AbemaTVのリニア型配信 ・配信品質の管理 1. MPEG-DASHによるリニア型配信 AbemaTV Developer Conference 2017 Yusei YAMANAKA 2. 自己紹介 3. 山中勇成 @toriimiyukki 株式会社サイバーエージェント 2017年新卒 株式会社AbemaTV サーバサイドエンジニア 配信チーム (負荷対策チーム) 4. 「中3で初めて生放送サービスを作った」AbemaTVで働く最年少エンジニアとは？ https://www.wantedly.com/companies/abema/post_articles/64961 5. 本日のアジェンダ ・MP
マンションのLAN内のゲートウェイが中間者攻撃してくるお話 - Qiita
来歴 私は去年、とある賃貸マンションへ入居した。 インターネットは無料で利用可能、壁の端子にLANケーブルを挿すだけ。 ただ、この物件のインターネット回線がおかしい。1日に1回くらい、Webサイトを閲覧しようとしたときに、マンションの管理会社のホームページへリダイレクトされる現象が起きる。 イメージとしてはこんな感じ。 東京の天気が表示されるべきなのに、入居者用Webページのログイン画面へリダイレクトされる。 腹が立ったので今年の5月くらいに現象を調べ、原因がわかったことで満足していたが、重い腰を上げて結果を以下の記事にして公開する。改めてGoogle先生に聞いたら、同じことで悩んでいる人がいた。 自動リダイレクトの回避方法について。 http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q10165027165 なお、後述の図には
GraphQLは何に向いているか - k0kubun's blog
今年GitHubがGraphQL APIを正式公開したあたりから、GraphQLが去年とかに比べちょっと流行り始めたように感じる。idobataがGraphQL APIを公開したり、Kibelaも公開APIをGraphQLで作ることを宣言している。 利用者側からすると使えるインターフェースの中から必要なものを調べて使うだけなのであまり考えることはないのだが、自分がAPIを提供する立場になると話は変わってくる。REST APIとGraphQL APIはどちらかがもう一方のスーパーセットという風にはなっておらず、どちらかを選択すると何かを捨てることになるので、要件に応じてどちらを選ぶのが総合的に幸せなのか考える必要がある。 以前趣味でGitHub連携のあるサービスを作っており、それを最近GraphQL API v4を使うように移行し、そこでついでにそのサービスのGraphQL APIを書いてみ
HTTPで「418 I’m a tea pot」を実装してはいけない(2018/10/18追記) - Qiita
418 I’m a tea potとは ステータスコード 418 I’m a tea potは、エイプリルフールに発行されたジョークRFCであるRFC2324「Hyper Text Coffee Pot Control Protocol」 で定義されているステータスコードです。 Googleでも 418 を返すURLがあります。 Error 418 (I’m a teapot)!? https://www.google.com/teapot 昨日、golangとnodejsにおいて、418 I’m a tea pot の実装を削除するIssue が投げられています。 golang: net/http: remove support for status code 418 I'm a Teapot nodejs: 418 I'm A Teapot #14644 Issue中でも書かれている通
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Safe Retry with Idempotency-Key Header
GraphQL対REST - 考慮すべき点