GraphQLとRESTfulについて今日考えてたこと Backend for Usecase/Resourceについて - 余白
DISCLAIMER: これは本当にただのメモ書きで、これがベストプラクティスだとかいう話ではないので、同じようなことを考えてる人いたら今度議論しましょうよ、って程度の話の種。 GraphQLを使うべきスポット、RESTfulが好ましいスポットについて今日ぼんやり考えていて、なんとなく言語化ができる気がするので文字起こししてみる。 Backend for UsecaseとBackend for Resource バックエンドのAPIには2種類あって、 「データ」を構成する「リソース」を提供するもの アプリケーションの「ユースケース」がもつシナリオのなかで登場する「データ」部分を埋めるためのもの を区別することが必要そう、と思っている。 まず前者を Backend for Resource (BFR)と呼ぶことにする。これはわかりやすくて、これはまさしくRESTfulそのもの。 RDBやそう
Node.js + GraphQLでBFFを作った話 - Qiita
whoami @qsona (Twitter, GitHub, Qiita) Node.js developer FiNC 2016/2 〜 Ruby, Rails / MySQL love microservices! Microservices Meetup 主催 昨日3/30に開催: vol.5 (API Gateway & BFF) BFF とは? Backends for Frontends の略 クライアントとバックエンドの中間にサーバを置き、フロントエンド寄りの処理を行う Microservicesの文脈で語られることが多い 昨日の会長のスライド step by step BFF GraphQL とは? クエリー型 Web API RESTful API において問題になりがちな点をカバーしている 仕様として定められている (RESTfulはあくまでAPI設計の指針) Nod
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
APIデザインケーススタディ —— Rubyライブラリを移植する前に読む本 - 世界線航跡蔵
『 APIデザインケーススタディ 』という本を頂戴したので読んでみた。 ライブラリ作者に向けて この本はRuby標準ライブラリを題材にして、分かりやすく、多様な機能をサポートして、互換性を保つAPIの設計をするにはどのように考えるべきかを教えてくれる。 ここでAPIと言っているのは、一般的なRubyのクラスとオブジェクトとメソッドから成るライブラリをどうデザインするか、という話である。 別にChef RecipeやRSpec DSLのようなちょっと変わったDSLを設計するとかそういう話ではない。確かにその種の言語内DSLのデザインには固有のセンスが必要とされるし、 Ruby DSL Handbook なんて本が書かれているように実装にあたってもある種のテクニックが必要なのも確かだ。でも、それ以外の「ふつう」のライブラリのデザインは果たして簡単だろうか。 適切な粒度のクラスを定義する。必要な
アプリエンジニアから見てAPI設計において気をつけてもらえるとうれしいこと - Qiita
by @mixiappwchr アプリ向けのAPIの開発時に気をつけてもらえるとうれしい＆メンテナンスや実装コストが下がる点をつらつら書きます。 データ構造について データを返すとき、一定のルールを守って返す。例えば当然ですが同じデータ構造はもちろん、似たような構造もルールを作ってproperty名などそろえておく。relationやlistで返すときもどのデータ構造なのかがpropertyで明確にわかるようなっているようにする listを返す場合の形式やpagingが必要な場合の形式はそろえる。配列のデータがない場合も考慮しておく。例えば、データがない場合にNULLにするか or 空配列にする or property自体がないなどきめる pagingの場合とか複数のパターンが存在することを覚えておくと幅が広がる。単純なページング or twitterみたいなsince_idなど起点id以
APIのエラーハンドリングを見直そう - WebPay Engineering Blog
ここ数ヶ月にわたって、WebPayはAPIのエラーにまつわる変更を少しずつ行ってきました。 それに付随してドキュメントも拡張しましたが、変更の背景について十分に説明できていない部分がありました。 この記事では、最近のエラーに関連した変更の背景を紹介し、今後どのようにエラーをハンドルすべきか説明します。 記事の内容は執筆時点のものであり、今後同じようにエラーやAPIの変更を行うことがあります。 変更があっても記事の内容はその時点の内容を保持し、ウェブサイトのドキュメントのみ更新します。 必ずウェブサイトのドキュメントを合わせて参照し、手元で動作確認を行ってください。 エラーはなぜ起きるのか WebPayのAPIは、リクエストされた操作ができなかったときにエラーを返すように設計しています。 可能なかぎりエラーにならないような設計、実装を心がけていますが、エラーは絶対に避けられません。 例えば、
Web API: The Good Partsを読んだ - AnyType
Web API: The Good Parts 作者: 水野貴明出版社/メーカー: オライリージャパン発売日: 2014/11/21メディア: 大型本この商品を含むブログ (1件) を見る 業務ではiOSアプリとバックエンドの開発を両方担当しているので、APIの設計を何回かやってきた。しかし、自分なりのやり方でやってきた部分が多かったので、最近発売されたWeb API: The Good Partsを読んでちゃんとした設計について学ぶことにした。 得られた学びをメモとして残す。 HATEOAS HATEOAS（Hypermedia As The Engine Of Application State）という設計方法を初めて知った。HATEOASではまず、サーバー側はレスポンスに関連するエンドポイントを含め次にアクセスするAPIを簡単に辿れるようにする。クライアント側は最初のエンドポイント以
Ruby RoguesメンバとiOSエンジニアのAPI議論 - ワザノバ | wazanova
http://rubyrogues.com/147-rr-apis-that-dont-suck-with-michele-titolo/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約4時間前 iOSエンジニアのMichele Titoloは、Objective-Cのディペンデンシーを管理するCocoaPodsのプロジェクトで知られてますが、モバイルエンジニアの立場からAPIを利用して開発するポイントについても、自らのブログでまとめています。 1) Follow Conventions はじめてのことにトライするときは先駆者の知恵に従うほうが、クオリティの高いものをつくれるので、conventionに従うのがよい。そのほうがデバッグもしやすい。自分でAPIのルールを定義する必要が生じた場合は、一貫性を維持し
例えば OSFA な API をやめる - @kyanny's blog
OSFA == one-size-fits-all 単一の API で全てをカバーするのをやめたらどうか、ということ。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight @kenn 最近はRESTfulなエンドポイントは完全に後方互換なまま、クライアントごとにオーケストレーション層(radical versionin)を設けるという方向にシフトしようとしている。詳しくは http://t.co/zODm7mFr5B— Tatsuhiko Miyagawa (@miyagawa) February 28, 2014 この話のポイントとはちょっとずれてる && Podcast 聴いてないのですが。 Quipper プラットフォームで内部的に利用されている API も、 /v1 というパスの下にはえててごく一部のエンドポイントだけ /v2 がある、み
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
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 API 設計のベストプラクティス集 "Web API Design - Crafting Interfaces that Developers Love" - フリーフォーム フリークアウト
移転しました http://please-sleep.cou929.nu/20130121.html
“API design for humans” をざっくり日本語にしてみた « blog.udzura.jp
37signals Signal vs. Noise で投稿されたブログ記事、面白そうなので日本語にしてみた。特に許可をとってたりとかしてないし、そんな厳密に原文をなぞってないですけど、まあ緩く。原文を必ずあわせて読みましょう。 37signals でデータを取り扱う仕事の終着点のひとつとして、たくさんのバラバラの API を取り扱うことがある – 私は少なくともこの数か月間で、10以上のサードーパーティ API を利用し、それと同時に我々の持っているすべてのパブリック API と、さらに多様な内向けインターフェースを取り扱ってきた。いくつもの違った言語で書かれたラッパーを利用し、いくつかは自分自身で書いた。こんな私が API の設計 – デザインとドキュメントに関して、利用者として強い意見を持っていたとしてもおかしくはないだろう。 私の経験上、 API のユーザビリティに真に関係する要素
API design for humans
One of the things about working with data at 37signals is that I end up interacting with a lot of different APIs—I’ve used at least ten third-party APIs in the last few months, as well as all of our public APIs and a variety of internal interfaces. I’ve used wrappers in a couple different languages, and written a few of my own. It’s fair to say I’ve developed some strong opinions about API design
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
まだAPI定義管理で消耗してるの？〜Swaggerを用いた大規模アプリ時代のAPI定義管理とコードジェネレート〜