GraphQLとRESTfulについて今日考えてたこと Backend for Usecase/Resourceについて - 余白
DISCLAIMER: これは本当にただのメモ書きで、これがベストプラクティスだとかいう話ではないので、同じようなことを考えてる人いたら今度議論しましょうよ、って程度の話の種。 GraphQLを使うべきスポット、RESTfulが好ましいスポットについて今日ぼんやり考えていて、なんとなく言語化ができる気がするので文字起こししてみる。 Backend for UsecaseとBackend for Resource バックエンドのAPIには2種類あって、 「データ」を構成する「リソース」を提供するもの アプリケーションの「ユースケース」がもつシナリオのなかで登場する「データ」部分を埋めるためのもの を区別することが必要そう、と思っている。 まず前者を Backend for Resource (BFR)と呼ぶことにする。これはわかりやすくて、これはまさしくRESTfulそのもの。 RDBやそう
《REST思想》と《リソース指向》と《Webページ》を一緒にしてはいけない - Qiita
はじめに Ruby on Rails や同種のフレームワークを使っていると、《REST思想》と《リソース指向》と《Webページ》がごちゃまぜになったWebアプリケーションをつい設計してしまいます。 三つの違いを意識し、適切なWebアプリケーションを作成するようにしましょう。でないと後悔することになります。 なお、この三つの用語は本来の意味とずれているかもしれません。 「コメント」、「編集リクエスト」大歓迎です。 解説 http://yourhost/books のURLで本の一覧が取得できるようなWebサービスを提供するとします。 では /books を含めた各URLはどのように振る舞うべきなのでしょうか。 （URLと言っている部分でも実際はpathを指している場合があります。ご了承ください）
Device Specific API Design - r7kamura per second
The Netflix Tech Blog: Embracing the Differences : Inside the Netflix API Redesign Netflixの開発者ブログで触れられているように、Netflixは以下の4つの方針に沿って彼らのAPIを再構築した。 デバイスごとの差異を受け入れる コンテンツの収集と整形を分ける クライアントとサーバの境界線を再定義する 変化を促進する デバイスごとの差異を受け入れる REST APIのように1つの汎用的なインターフェースで全ての要件を満たそうというアプローチは、 APIへの理解が簡単になる一方、後から変更することは難しくなり、また非効率な処理を生み出しやすくなる。 この手のアプローチが重視しているのは、API提供者側の開発コストを下げることであり、 API利用者の利便性を第一に考えたものではないと彼らは考える。 API
Favoriteの設計実装はパターンとして使える - Qiita
RailsでのfavoriteのURL設計 http://d.hatena.ne.jp/tkawa/20110508/p1 かなり前にこういう記事を書いたのですが、最近たまたま似たものをRailsで何回か実装する機会があって、これはいろんなところで使えるんじゃないかと思ったので、その設計実装パターンを紹介してみます。 モデル 任意のツイートに任意のユーザーがお気に入りをつけられるというもの。別にツイートじゃなくても何でもOKです。 class Tweet < ActiveRecord::Base has_many :favorites end class User < ActiveRecord::Base has_many :favorites end class Favorite < ActiveRecord::Base belongs_to :tweet belongs_to :use
リソースモデリングパターン
Webアプリケーションについて、RESTfulなURL・リソース設計のパターンを見出すことで、 どのパターンかを判断するだけで、既存の Good Practice が適用できる 名前をつけて呼べるようにしたい Railsなどのフレームワークで簡単に適用できるようにしたい ということを目指しています。 ほんとうに役立つか これはパターンと言えるのか もっと他にもある だいぶ粒度がバラバラ 名前の付け方（パターンは名前重要） など、ぜひご意見をください。 パターン Collection & Member Resource パターン Singular (Singleton) Resource パターン Filtered Collection パターン Filtered Subresource パターン Multi-member Resource パターン Partial Resource パター
RailsでのURL設計を考えてみる(5) Railsのリソースパターン - ぶろぐ。@はてな
URL設計の前段階として、とても大切なのがリソース設計です。そのWebアプリ・Webサービスで何を提供するのかが決まる部分だからです。しかし、なかなかリソースという概念が定着していないようなので、Railsで採用されているパターン*1を例に挙げて紹介してみたいと思います。 今までのシリーズ記事と重なるところもありますが、まとめということで…。 リソースとは 簡単に言うと、「URLで示されるもの」です。URLというのが“Uniform Resource Locator”の略ですからね。 http://d.hatena.ne.jp/tkawa/20110819/p1 http://d.hatena.ne.jp/tkawa/20110819 最初のものは、前回書いたブログ記事『RailsでのURL設計を考えてみる(4) スラッシュと「持っている」関係』というリソースです。 その次は、『tkawa
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
