「GraphQLは何に向いているか」に対してのちょっとした反論 - 病みつきエンジニアブログ
k0kubun.hatenablog.com 非常に丁寧に書かれていると思うのですが、少し反論したい部分があるので、記載したいと思います。 GraphQLのキャッシュ効率について クエリをパースしないとキャッシュの可否を判定できないため、HTTPキャッシュが難しい こちらに関して、２つの観点から反論してみたいと思います。 まずに、GraphQL は GET リクエストでも送ることができます。Serving over HTTP | GraphQL によると、http://myapi/graphql?query={me{name}} のような URL の GET リクエストができます。(※そもそも、これ自体は GraphQL の絶対的な制約ではなく、 GraphQL を一般的に HTTP で提供するときのプラクティス、という位置づけです) そして、GraphQL は 1 回のリクエストで送らな
XSSやCSRFリスクを軽減する、Entry Point Regulationとは - ASnoKaze blog
Entry Point Regulation とは 反射型XSS・XSSI・CSRFのリスクを軽減するユーザエージェント上の仕組みとして、W3CでEntry Point Regulationという仕様が策定中です。 Webアプリケーションの口(Entry Point)に幾つかの制限をかけることが出来ます。別オリジンからのリクエストの時に、クエリパラメータやHTTPリクエストボディ(POSTメソッド)が付いていればブロックする、と言った事がマニフェストで指示できるようになりそうです。 EPRにおけるリクエストカテゴリ 各エンドポイント(URL)はどのようなリクエストを受け付けることが可能か指定できます。その時に指定するリクエストは以下に分類されます navigational request：context frame typeは"top-level", "auxiliary", "neste
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
