【徹底解説】REST VS GraphQL
注意：今回の記事で載せているコードは読者に具体的なコードのイメージを持たせる目的で書いている。それ故に、実際にブラウザ上で実行しても動作しない点には注意してほしい。より専門的ににGraphQLとRESTの違いを学びたいならLogRocketの記事とApolloの記事を参考に。 はじめに 今回の記事では、Web APIの開発に重宝されるRESTとGraphQLの違いを解説する。 対象とする読者 これからREST、またはGraphQLを実務で積極的に活用したいひと 両者の違いがわからないひと 個人開発等でWeb APIをつくるひと タイトルを見てなんとなく気になったひと APIとは RESTとGraphQLの議論に入る前に、まずはAPIについて説明する必要がある。 Wikipediaによると、API(Application Programming Interface)は以下のように定義されてい
RESTとトランザクション - Qiita
状況 あなたはいま新たなWEBサービスの開発に, サーバサイドのプログラマとして参加しています. このサービスはJavascriptで動くクライアントサイドと, REST形式のAPIを提供するサーバサイドで構成されています. 初期の打ち合わせの結果, サービスのビジネスロジックは最大限クライアントサイドに実装し, サーバサイドはDBの薄いラッパー程度の簡単なものとして実装していく方針でまとまりました. サーバサイドの開発は順調に進んでいっていました, ある日クライアントサイドのプログラマからこんな相談を受けるまでは. 「この画面の処理で３種類のリソースを保存する必要があるのだけれど, いずれかの処理に失敗した場合は 残り２つのリソースに対する変更も取り消したいたいんだ. どうやったらいいと思う?」 当然ながら, DBMSが提供するトランザクション機能が使えれば特に問題のない話ではある. し
RESTful APIのURI設計(エンドポイント設計) - Qiita
RESTful APIのリソース設計で述べた通り、何をリソースとするかを決めたらそのリソースを識別するURIを検討する必要がある。 エンドポイントとは何か エンドポイントとはAPIにアクセスするためのURIのこと。例えば、QiitaのAPIで自分の情報を取得する時のエンドポイントは以下となる。 http://qiita.com/api/v2/users/nagaokakenichi 似たような言葉に「エントリポイント」というものがある。エントリポイントとはプログラムやサブルーチンの実行を開始する場所のこと。 Qiita視点で考えると、 http://qiita.com/api/v2/users/nagaokakenichi を参照されることでプログラムが開始されるので、Qiitaからすると上記URIはエントリポイントとなる。 つまり、エンドポイントはAPIにアクセスする側からの、エントリポ
翻訳: WebAPI 設計のベストプラクティス - Qiita
これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公
Web API 設計のベストプラクティス集 "Web API Design - Crafting Interfaces that Developers Love" - フリーフォーム フリークアウト
移転しました http://please-sleep.cou929.nu/20130121.html
RESTful Web Services より良いWebインタフェースの構築と分散型システム連携：第1回：RESTのコンセプトと特徴 ～REST を知ると考え方が変わる～ | 豆蔵ソフト工学ラボ
RESTful Web Services より良いWebインタフェースの構築と分散型システム連携 第1回：RESTのコンセプトと特徴 ～REST を知ると考え方が変わる～ 印刷 株式会社豆蔵 BS事業部 コンサルタント 五味 和人 2009/10/02 ［アーキテクチャ］ 現在、一般的になりつつある REST (REpresentational State Transfer) ですが、いざ実践しようとするためには、正しい理解と実装指針が必要です。前編となる本記事では、REST の概念をご紹介し、後編となる次記事では、一般的に言われている勘所と、私が実プロジェクトで実践した勘所についてご紹介します。 1. SaaS/PaaSとREST SaaS(Software as a Service)やPaaS(Platform as a Service)、クラウドといった言葉をよく耳にします。 We
RESTful Web アプリの設計レビューの話
Visual Studio Users Community Japan #1 で発表した資料になります。 https://vsuc.connpass.com/event/143114/
最近のRESTの進化。バージョン番号、状況報告、プロダクトとしてのAPI
RESTの時代がやってくるのだ、という記事を1つ前の「時代はRESTへ。SOAPの終わりを象徴する、Webサービス標準化団体のWS-Iが活動終了」で紹介しましたが、そのRESTも使われ方が進化してきているのだ、ということを、その記事の中でとりあげたProgrammableWebのJohn Musser氏が公開しているの資料の中で解説しています。 3つ紹介しましょう。 バージョン番号の組み込み 最近のREST APIにはバージョン番号がURIに埋め込まれるようになったとのこと。 利用者に状況報告 レイテンシーがどうなっていて、正常稼働しているかどうかといった報告を利用者に対してきめこまかく報告するようになったと。APIに依存した外部サービスが増えたためでしょうね。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
InfoQ: 実践RESTful HTTP