GraphQLはいつ使うか、RESTとの比較
さぼです、沖縄でWebと設計について考えてます。2023/09/23 に沖縄で行われたTechBaseOkinawa2023 にて上記のタイトルで登壇しました。 今回の内容は GraphQLを設計の観点から考えてみる GraphQLの目的や用途を整理する GraphQLを使う時、または使わない時のヒントを持ち帰ってもらう 最近、GraphQLじゃなくてRESTで良くないと思うケースがなんとなくわかってきたのでそれを共有する という感じで話しました。話した内容を文字に起こし少し改修してZennでも共有することとします。 まえおき 最近はクライアントAppとサーバーAppを分けて実装する事が増えてきた クライアントの環境はますます複雑になっている クライアントとサーバーはWebAPIで通信を行う クライアントが複雑になるのと同時にWebAPIの要求が更に増して来ている APIの要求・応答を効率
RESTful のウェブ API 設計で避けるべき 6 つのよくあるミス | Google Cloud 公式ブログ
※この投稿は米国時間 2022 年 12 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。 オンラインで、組み立て式のテーブルを注文したとします。ところが、パッケージを開けてみると、組立説明書が入っていません。完成品がどんなものかはわかっていても、それぞれのパーツをどう組み立てればいいのか、まるでわかりません。設計が不十分な API を使うコンシューマ開発者も、同じような経験をしているといえます。適切に設計された API なら、容易に見つけ、検索してアクセスし、使用することができます。高品質の API は、コンシューマ開発者がアイデアをひらめき、新しいユースケースを作り上げる手助けになってさえくれます。 もちろん、API 設計を改善する方法はあります。たとえば、RESTful のプラクティスに従うなどです。しかし、お客様が知らず知らずのうちに、ちょっとした不便
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を書いてみ
espressologic.com - このウェブサイトは販売用です！ - espressologic リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
リソースモデリングパターン
Webアプリケーションについて、RESTfulなURL・リソース設計のパターンを見出すことで、 どのパターンかを判断するだけで、既存の Good Practice が適用できる 名前をつけて呼べるようにしたい Railsなどのフレームワークで簡単に適用できるようにしたい ということを目指しています。 ほんとうに役立つか これはパターンと言えるのか もっと他にもある だいぶ粒度がバラバラ 名前の付け方（パターンは名前重要） など、ぜひご意見をください。 パターン Collection & Member Resource パターン Singular (Singleton) Resource パターン Filtered Collection パターン Filtered Subresource パターン Multi-member Resource パターン Partial Resource パター
REST APIs must be hypertext-driven » Untangled
I am getting frustrated by the number of people calling any HTTP-based interface a REST API. Today’s example is the SocialSite REST API. That is RPC. It screams RPC. There is so much coupling on display that it should be given an X rating. What needs to be done to make the REST architectural style clear on the notion that hypertext is a constraint? In other words, if the engine of application stat
Web API Design(その１) - winplusの日記
これApigee | Google Cloud Blogを勝手訳してみる。InfoQの紹介記事Web API Design - 開発者が愛するインターフェイスを作るで十分かも知れませんが、まあ。 導入 これを読んでいるということは、開発者に愛されるようなWeb API をデザインすることを気にかけているのでしょう。そして、実証済のデザインの原則とベストプラクティスとをWeb APIに適用することに関心があるのでしょう。 私たちがデザインを考えるのためのソースのひとつに、RESTがあります。なぜなら、RESTは厳格な標準ではなくアキーテクチュア・スタイルであり、かなりの柔軟さを認めているからです。構造が柔軟かつ自由であるからこそ、デザインのベスト・プラクティスを貪欲に追い求めるのです。 このe-bookはデザインのプラクティスを集めたものです。収録したプラクティスは、私たちがいくつかの世界中
RESTをとるか、WebSocketをとるか : iwamotのブログ
2012年04月05日01:53 カテゴリ RESTをとるか、WebSocketをとるか どうせWebアプリケーションを作るのなら、できるだけRESTfulに作りたい、と僕は今でも思っている。 とはいっても、セッションIDをcookieに保存する例のように、あえてRESTのスタイルを崩すべき場合もあろう。 非同期処理についても、RESTにこだわってジョブリソースを云々するより、WebSocketを使って完了をクライアントに伝えるほうが簡単だ。だから、スタイルを崩してWebSocketを使ってよい。 本当にそれでよいのだろうか。気になったので、RESTの提唱者であるRoy T. Fielding氏がWebSocketをどう評価しているのか調べてみた。理解に誤りがあればご指摘いただきたい。 Re: [hybi] WebSockets (2009-03-30) なぜWebページからのプッシュが必
Railsの誤解：CRUDはRESTじゃない！ - 杉風呂2.0 - A Lifelog -
以下はNick Sutterer氏が2010年10月28日に自身のブログに投稿した、"Rails Misapprehensions: CRUD is not REST! "の翻訳です。本人の許可を得て掲載します。 Rails Misapprehensions: CRUD is not REST! http://nicksda.apotomo.de/2010/10/rails-misapprehensions-crud-is-not-rest/ RailsとRESTについて調べている間、二つのことがよくわかった。 RailsでRESTがどうなっているのか、他と比べて、明解で、基礎的で、「印刷された」解説を見つけにくい。数千のスクリーンキャストを見てきたが、この素晴らしいガイドが一つあるだけだった。 みんなCRUDとRESTを混同している とりわけ後者は僕を困らせたが、あるチームをコーチすると
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Exposing CQRS Through a RESTful API