GraphQLはRESTの置き換えではない｜こんぴゅ
GraphQLは最近注目されているWeb APIのための問い合わせ言語だ。 現在主流のRESTfulなAPIはURLとmethodでリソースを表現するわけだが、GraphQLは単一エンドポイント（ex: "POST /graphql"）だけ存在し、欲しいリソースをHTTP POSTのbodyに明示的に記載してリクエストする。 ↑JSON APIをGraphQLの形式でコールする（引用: how to graphql ) 徐々に実装例が増えてきており、2016年にはGithubがAPIの実装を全面的にGraphQLに移行させたのが注目された。 色々調べていくと、GraphQLは単にRESTの代替ではなく、開発・運用フローを一新させうるほど豊かな思想・機能を含む事が分かって来たので現状の整理をしてみたい。 APIリクエストを束ねて効率化RESTではURLがひとつのリソースを表すため、複数のリソ
API Blueprint | API Blueprint
API Blueprint. A powerful high-level API description language for web APIs. API Blueprint is simple and accessible to everybody involved in the API lifecycle. Its syntax is concise yet expressive. With API Blueprint you can quickly design and prototype APIs to be created or document and test already deployed mission-critical APIs. Tutorial Tools section Focused on Collaboration API Blueprint is bu
GraphQLはWeb APIの次のフロンティアか？ | POSTD
RESTの規約。URLはリソースであり、CRUDはHTTP動詞にマップされる。 RESTの規約に1つ問題があるとすれば、規約が十分でないということでしょう。上記で”通常”、”多くの場合”、”時に”という表現を使ったのは、これらのやり方は仕様で推奨されているものの守られるとは限らないためです。実世界では、大抵のAPIはRESTishがせいぜいです。例えばStripeでは、リソース更新に PUT ではなく PATCH を使うべきですが、歴史的理由でそうはなっておらず、おそらく現時点では変更に値しないでしょう。いずれにしても開発者はドキュメントを読む必要があり、その時、 POST メソッドのユビキタスな使い方があることに気づくのです。 RESTには他の問題もあります。必要なものだけでなく全てが返ってくるため、リソースのペイロードが非常に大きくなることがあるのです。そして多くの場合、クライアントが
JavaScript で クラスベースの設計より関数指向の実装を薦める理由 + GraphQL について - mizchi's blog
最初に: 「Functional Programming 最高！」という話ではないです JSは通信やストレージに保存するデータの扱いの関係で、JSONにシリアライズできることが至上命題になるケースが多いので、クラスベースの設計で自身に副作用を起こすメソッドより、イミュータブルな T => T なstatic methodとして切り離しておくと扱いやすいケースが多い— 現場の声 (@mizchi) 2016年9月6日 複雑なオブジェクトのシリアライズは簡単だけど、逆にシリアライズされたオブジェクトからビルダを構築するのが難しいので、JSONの構造体自身とは別に独立して独立したメソッドとしてビルダが切り離されている方が扱いやすい— 現場の声 (@mizchi) 2016年9月6日 一応コンストラクタ名を保存してシリアライズ/復元する方法はあって、RPGツクールMVのコードを読むとそういう感じに
JSON Web Token の効用 - Qiita
Note: JWT の仕様やそもそも論の話は触れません。どう使うか、何が出来るかしか書いていません。 JSON Web Token? JSON Web Token とは、ざっくりいって署名の出来る JSON を含んだ URL Safe なトークンです。 署名とは、署名時に使った鍵を用いて、JSON が改ざんされていないかをチェック出来るようにすることです。 URL Safe とは、文字通り、URL に含めることの出来ない文字を含まないことです。 これだけだとよくわかりませんが、触り心地としては次のような性質があります。 発行者だけが、鍵を使ってトークンが正しいことを検証出来る。 暗号化ではないので、JSON の中身は誰でも見られる。 仕様的には、暗号化のオプションもあります。 しかしながら、JSON の変更は出来ない。（改ざんをすると、検証時に失敗するので。） 全体的には、なんか変更できな
HTMLでWeb APIをつくる - Qiita
シングルページアプリケーションやモバイルアプリなどの普及により、サーバサイドではJSONを出力するWeb APIの必要性が高くなってきています。みなさんはどのようにWeb APIを作っているでしょうか。 JSONはビュー RailsでJSON APIを定義する時、素のままでやろうとすると コントーラでto_jsonを呼んだり、モデルにas_jsonを定義したりすることになるかと思います。 モデルに書くとAPIによって出力内容を変えたい場合にとても苦労します。 API数が増えれば増えるほどモデルが複雑になっていきます。 APIレスポンスとしてのJSONはコントローラやモデルに書くべきでしょうか？ ビューに書いた方が自然ではないでしょうか？ これはRailsでの話ですが、Railsに限らず、フレームワークを使ってWeb APIを作るときに一般的にあてはまることだと思います。 変化に強い、再利用
HerokuのつくってるAPI関係の便利なやつ - ✘╹◡╹✘
JSON Schema for the Heroku Platform APIでも紹介されているように、HerokuのAPIはJSON schemaで記述されたAPIの仕様を返すようなAPIがあって(ややこしい)、Auto-generating a Go API client for Herokuのようにこれを利用してAPIクライアントを自動生成するようなこともやってる(単なるアート作品じゃなくて実際に運用されているので偉い)。Herokuが出してるAPI関連作品の1つにcommittieというのがあって、JSON schemaを利用してAPIの仕様を定義して、それをRack middlewareで利用しようというもの。前に試しに似たようなのつくってたので良いのが出てきて良かった。 Committieは大きく分けて3種類の機能を提供していて、1つは本番環境で普通に使うやつで、リクエストをv
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
