RESTful API の設計のキホン
2016/10/12 社内勉強会で使ったスライドを社外向けに一部加筆訂正したもの
Phoenix でバージョニングした REST API を構築する - FIVETEESIXONE
簡単な API サーバーを作る必要があったので、Elixir の WAF である Phoenix を使ってみました。API バージョンでスコープを分けた RESTful API 構成にしようとしたのですが、なんだか結構ハマってしまったので簡単な手順を残します。 title と completed という2つのフィールドを持つ todo という単純なリソースを例とします。 アプリケーションの作成 phoenix.new タスクで新規の Phoenix アプリケーションを作成します。このとき、今回は REST API リソースを構築するので、アセットを管理するためのツールである Brunch は不要です。したがって --no-brunch オプションをつけて実行します。 $ mix phoenix.new rest_api_example --no-brunch これで、Phoenix アプリ
RESTのベストプラクティス | POSTD
現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR
IMVU Engineering Blog – Software engineering best practices at IMVU
While writing the source code of a 3D engine, we can have many types of problems. These may range from simple problems of code that will not compile, to harder problems like memory leaks. At IMVU, we have automated solutions in place to help find these kinds of problems. For example, unit testing combined with Valgrind has helped us track down a lot of memory leak problems. But what about performa
アプリ向けのサーバーAPIは「REST」 or 「WebSocket」？
アプリとサーバー間のやりとりをREST APIかまたはWebSocketで実装するか迷ったときの覚書。 よくまとまっているサイト WebSockets versus REST? （上記サイトの日本語訳）WebSockets vs. REST? 今のところ「共存出来るんだから、それぞれの特性を理解して使い分けろ」に落ち着いている感じ。 WebSocketでやりとりするメッセージにルール付けして、RESTを表現しようとする動きもある。 SwaggerSocket Protocol · swagger-api/swaggersocket Wiki NginxはWebSocketをリバースプロキシ出来るし、ロードバランサとしても動作する。 NGINX as a WebSockets Proxy - NGINX ExpressJSとSocket.IOでセッションを共有出来る。 node.js - s
HerokuのAPIデザイン
Herokuが自ら実践しているAPIデザインガイドをGithubに公開した． “HTTP API Design Guide” このガイドは些細なデザイン上の議論を避けて，ビジネスロジックに集中すること目的としている．Heroku特有なものではなく，一般にも十分適用できる知見となっている． 最近は，モバイル向けにAPIをつくることも多いため，勉強もかねて抄訳した．なお内容は，HTTP+JSONのAPIについて基本的な知識があることが前提となっている． 適切なステータスコードを返す それぞれのレスポンスは適切なHTTPステータスコード返すこと．例えば，“成功"を示すステータスコードは以下に従う． 200: GETやDELETE，PATCHリクエストが成功し，同時に処理が完了した場合 201: POSTリクエストが成功し，同時に処理が完了した場合 202: POSTやDELETE，PATCHリク
Netatmo ウェザーステーションを買ってみたので Node.js でいじってみた - 凹みTips
はじめに Netatmo という商品はご存知でしょうか？ 【日本正規代理店品・保証付】Netatmo ウェザーステーション NET-OT-000001 出版社/メーカー: Netatmo発売日: 2013/10/10メディア: エレクトロニクスこの商品を含むブログ (1件) を見る 【レビュー】台風の接近も記録：スマホと連携するスタイリッシュな気象センサー『Netatmo ウェザーステーション』 | Touch Lab - タッチ ラボ Netatmo ウェザーステーション - Apple Store (Japan) 屋内と屋外に設置して、「温度」「湿度」「気圧」「二酸化炭素濃度」「騒音」を iOS や Android アプリからモニタリング出来るガジェットです。IFTTT 連携も出来るので、例えば二酸化炭素がアレになったら通知とか、気圧が 1000 hPa を下回ったらつぶやくとか出来ま
《REST思想》と《リソース指向》と《Webページ》を一緒にしてはいけない - Qiita
はじめに Ruby on Rails や同種のフレームワークを使っていると、《REST思想》と《リソース指向》と《Webページ》がごちゃまぜになったWebアプリケーションをつい設計してしまいます。 三つの違いを意識し、適切なWebアプリケーションを作成するようにしましょう。でないと後悔することになります。 なお、この三つの用語は本来の意味とずれているかもしれません。 「コメント」、「編集リクエスト」大歓迎です。 解説 http://yourhost/books のURLで本の一覧が取得できるようなWebサービスを提供するとします。 では /books を含めた各URLはどのように振る舞うべきなのでしょうか。 （URLと言っている部分でも実際はpathを指している場合があります。ご了承ください）
例えば 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のバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
This domain name is registered with Netim
Netim offers nearly 1,000 geographical (ccTLDs) and generic (gTLDs) extensions. Find the perfect domain name Netim regularly offer discounts on domain names. Some extension start at $1.50 excl.tax for the first year. Discover all of our special offers Whether your website is personal, professional or an online store, you will find the perfect offer for your projects! Discover our web hosting plans
世の中のHTML5アプリケーションが糞だから、俺が「初期化」の作り方を教えてやんよ - mizchi's blog
2chまとめみたいなタイトルにしてみた。(してみたかった) HTML5のアーキテクチャと初期化とキャッシュの考え方が、「ウェブエンジニア」は本当に出来てない。 とくにソシャゲをウェブビューに貼ってスマホ対応しました系。本当にダメ。 じゃあどうするか？基本的に「初期化」の考え方を直せばどうにかなる。 (この記事はBackboneを使うときに考えてることだけど、他でも一緒だと思う) 前提 シングルページアプリケーション セマンティクスやSEOは考慮しない 基本哲学 共通モデルの初期化を徹底的に行う サーバーにリクエストを投げるのは最小限 クライアントでサーバーモデルのキャッシュを作り、更新が期待されるまで再取得しない 理由 いくらDOMの最適化したところでUXに影響が大きいのはサーバーリクエスト(200~2000ms)で、プログラミング段階で辛さがあつまるのは非同期処理の部分。 プログラマとし
Web API 設計のベストプラクティス集 "Web API Design - Crafting Interfaces that Developers Love" - フリーフォーム フリークアウト
移転しました http://please-sleep.cou929.nu/20130121.html
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
REST API設計のパターンと原則｜Sachiko Kijima
GitHub - flawiddsouza/Restfox: Offline-First Minimalistic HTTP & Socket Testing Client for the Web & Desktop
Building a versioned REST API with Phoenix Framework