アプリ向けのサーバー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
RESTful Web API 開発をささえる Garage - クックパッド開発者ブログ
技術部の小野(@taiki45)です。この記事では簡単なアプリケーション(ブログシステム)の実装を通して、クックパッドで作成・使用しているライブラリのGarage の紹介と Garage を使った RESTful Web API の開発をご紹介したいと思います。 Garage は RESTful Web API を開発するための、 Rails gemified plugins です。Rails プログラマは Garage を使って Rails を拡張することで素早く Web API を開発することができます。Garage は新しくアプリケーションを開発する場合にも、既存の Rails アプリケーションに組み込んで Web API を実装する場合でも使用できます。Garage はリソースのシリアライズやアクセスコントロールなど Web API の実装に必要な機能をカバーしています。 Ruby
RubyKaigi 2014 で Hypermedia Web API について発表しました - ぶろぐ。@はてな
9月18日の RubyKaigi 2014 (1日目) で “Hypermedia: the Missing Element to Building Adaptable Web APIs in Rails” というタイトルの発表をしました。 Hypermedia: The Missing Element to Building Adaptable Web APIs in Rai… from Toru Kawamura 時間オーバーしてしまったのが反省点ですが、発表後にまわりの方々から良かったという言葉をいただいて、Twitterなどを見ても好評だったようで、嬉しい限りです。ありがとうございます。 詳しい内容については、るびまに載せる予定なのでそちらに譲るとして、要旨は、“RESTful Web APIs” (O'Reilly) に書かれている内容から、エッセンスを自分なりにまとめたものです
Webサービスの認証方式 - In urban breeze
2014-04-27 Webサービスの認証方式 セキュリティ Basic認証 HTTPリクエストヘッダー内にユーザー名とパスワードをBASE64エンコードして送信する。 自分で打ち込まなくてもあらかじめヘッダーに入れておけば認証が通るというメリットがある。 フォーム認証 通常のウェブ画面のフォーム認証。 IDとパスワードはウェブサービス側で管理する。 OpenID フォーム認証だけでは、ウェブサービスの数だけIDとパスワードが必要になる。 そこで一つのIDとパスワードだけで様々なサービスにログインできるOpenIDが開発された。OpenIDを利用するには次の二つが必要である。 IDPまたはOP（OpenID Provider） OpenIDを発行してくれるプロバイダ RP（Relying Party) OpenIDを利用してログインできるサービス ここで「認証（Authentic
Web API認証について
最近、Web APIの認証をどうすべきか考えている。 例えば次のようなケースをどうするか。 「既存のWebサイトがあり、既にユーザＩＤとパスワードによる認証によって、ブラウザでデータを提供している。 今回、この提供データをブラウザの画面ではなく、REST APIにて取得可能にしたい。 このデータはユーザ毎に取得可能な値が違うので、認証、または認可によって制限をかけたい。」 ユーザーがブラウザからIDとパスワード(以下ID/PW)を使ってログインする方式を、そのままWeb APIにも適用しても安全なのだろうか。 Web APIの先にはスマホアプリやシェルスクリプトなどから直接ログインするものなどが考えられるが、安全かつシンプルに実装するにはどうしたらいいのだろうか。 私はセキュリティの専門家ではないので間違った考え方をしている可能性もあるが、誰かの目に留まって助言いただけるかもしれないので、
「API Meetup Tokyo #3」に参加してきました - ログ
2014年9月26日(金)に開催されましたAPI Meetup Tokyo #3に参加してきました。 本勉強会はApigeeさんが主催するもので、Web API に携わる開発・企画担当者が、API まわりの様々な要素技術や適用事例を一緒に学ぶオープンな勉強会であり、今回はその3回目となります。 ヌーラボサービスにおけるAPI設計・運用のこれまでとこれから 最初は、株式会社ヌーラボ テクノロジー・エバンジェリスト 染田 貴志さん(@tksmd)の発表 API Meetup #1、#2の振り返りとAPIの概観から、ヌーラボにおける実際のAPI設計・運用のお話をして頂きました。 なぜ今APIなのか これまでのAPIはデータの一部を取得できるなど補完的な役割だった これからはAPIがサービスそのものとなっていく APIエコシステム Evernoteでは、API連携したアプリケーションがユーザの満足
クックパッドとマイクロサービス - クックパッド開発者ブログ
技術部の高井です。 最近、日本でもマイクロサービスという言葉が流行しつつあります。 今回は、なぜクックパッドがマイクロサービスを選択したのか、また実際にどのようなやり方をしているのかということを紹介します。 Conwayの法則 ここ数年の間、クックパッドはレシピの投稿・検索サービスから「食を中心とした生活のインフラ」として事業領域を拡大しつつあります。海外レシピサービスの買収による海外展開は、単なる金銭的な関係にとどまらず、人的・技術的な交流も含めて本格化しつつあります。また、「モバイルファースト」を標語とするモバイルアプリケーションへの取り組みも加速してきました。 事業領域の拡大やグローバル展開、モバイルファーストといったビジネス要求の変化に応じて、会社の組織構造も変化しています。そして、Conwayの法則 として知られているように、組織構造とソフトウェアアーキテクチャには密接な関係があ
Squareの内部APIの仕組み - ワザノバ | wazanova
http://corner.squareup.com/2014/09/squares-api.html 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 SOAにおけるサービス間のコミュニケーションについては、CODE CLIMATEにおいて、Protocol Buffers vs JSONという比較が取り上げられていて、「ブラウザやJavaScriptが直接データを利用しないケース、特に内部サービス間のコミュニケーションにはProtocol Buffersの方が向いているのでは。」と紹介されています。 せっかく整合性のあるデータ構造を用意しても、サービス間のデータのやり取りの際に苦労させられることが多い。Protocol BuffersならProtoフォーマットにしてエンコーディングするだけで、意図す
RailsでAPIをつくるときのエラー処理 - Qiita
例外を利用して実装すると便利な場合が多い この投稿では、HTTP経由でJSONを返すようなWeb APIをRailsを利用して実装するとき、エラーレスポンスを返す場合の処理をどう実装するとやりやすいのか、というニッチな話題に触れる。APIでエラーを返したいとき、即ち400以上のステータスコードと共にレスポンスを返したいような場合、どう実装するのが良いか。もしリクエストの処理中にエラーが検出された場合、それ以降の処理を行わずに直ちに中断してエラーレスポンスを返したいという場合が多いため、例外を利用して実装すると便利な場合が多い。 例外を利用しない方が良い場合もある 1つのリクエストに複数の問題が含まれている場合、先に見つけた問題だけを報告するようなエラーレスポンスを返すのか、それとも問題を抱えながらも進めるところまで処理を進めて報告可能な情報を全て含むようなエラーレスポンスを返すのか、という
RailsでAPIを作るときのエラー処理について | Yucchiy's Note
RailsでAPIを雑に書いていたんだけど, コントローラとかをどう書くとエラー処理しやすくなっていいかなーと考えていて, 個人的に考えがまとまったのでブログ書いた. ※9/1に追記書いた. 良いエラー処理について 個人的にAPIを書く上で(API書くに限らない気はするけど)どういうふうにエラー処理を行うと良いかなーと考えてみると コントローラ内では基本的に, ある関数の処理が失敗して, 次の処理が行えない場合はすべて例外を投げる 例外は各々のコントローラ内で例外のキャッチは行わず, すべてApplicationControllerなど, 親コントローラ内の1メソッドで完結させる かなーと思う. APIのエラー処理は, Envelopeにステータスコードとエラーメッセージを書いて, APIのフォーマットを統一するほうがクライアントが作りやすそうだし, またこのように処理することで, エラー
クラウドサービスの Web API とそのユースケース #apijp
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
RESTとJSON、スキーマ定義について思うところ
mozaic.fm #7 RESTや#mozaicfm REST を聴いての感想、それから「Web+DB vol82のWebAPIデザインの鉄則」に触発されたので書こうと思う。 REST設計について WebAPIを設計するうえでRESTが重要であることは周知のとおりである。 “Constraints are liberating”「制約は自由をもたらす」 @t_wadaさんがおっしゃっているように、RESTを前提にすれば、「アーキテクチャとしてもそうだし、アプリケーションフレームワークも「適切な制約」を設けることで設計のコストが下がる」という大きなメリットが生まれる。 しかし、相変わらずリソース設計やらインターフェース設計やらで悩んでおられる方も多いと聞く。 その一方で個人的には適切なフレームワークを使えばREST設計で悩まなくてもよいはず(※3)という思いもある。 インターフェース設計な
#mozaicfm REST を聴いての感想 - ぶろぐ。@はてな
mozaic.fmでRESTの回が企画されているということを、API Meetup #1 のときに yohei さんから直接聞いていたのですが、ついにそれが公開されたので、喜び勇んで聴きました。 mozaic.fm #7 REST 断片的に感想をツイートしたので、そのまとめです。 RESTの何が重要なのか さすがの t_wada さん。アーキテクチャとしてもそうだし、アプリケーションフレームワークも「適切な制約」を設けることで設計のコストが下がる、という話の流れでした。 “Constraints are liberating”「制約は自由をもたらす」は僕が好きな言葉ですが、これを知ったのはDHHのRubyKaigi 2006の講演からです。（初出はどこか別のところなのかも？） RESTの流行 原理主義者的発言をするなら、「REST API」と謳って世に出たWeb APIはただのJSON/X
リトライと冪等性のデザインパターン - Blog by Sadayuki Furuhashi
リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の３つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から： なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ
API設計のポイント - ワザノバ | wazanova
Living Socialが7回に渡りSOA (Service-oriented architecture) についてのブログを書いてますが、今回はAPI設計についてのエントリーです。 「APIはRESTful」と言うだけでなく、社内でガイドラインがオーソライズされるように調整すること。設計にあたっての選択肢及び自由度をしっかり考慮すること。そして一番大事なのは、決めた原則とおりにブレなくインプリすること。 どのHTTPステータス（success/error）をどのシチュエーションで採用するか。 204もしくは200をPOSTで使うか？PUTで使うか？ 4xx番台のコードの一貫性。 bodyにエラーメッセージを追加するのか。 認証はどこで？ ヘッダー？もしくはURLパラメータ？ リソースの階層はどうするか。 忠実にRESTfulとするのか、RPCのようなエンドポイント（/inventory
「APIデザインの極意」のメモ - プログラマの思索
「APIデザインの極意」の感想Blogがとても素晴らしいのでメモ。 「APIデザインの極意」を買おうと思ったら、台風で警報が出ており、買いに行けないのが残念。 ラフなメモ書き。 【元ネタ】 アジャイルAPI設計時代の到来！？APIデザインの極意を読みました。 - シスアーキ in はてな ソフトウェア再利用の概念: プログラマの思索 ソフトウェア部品化の幻想: プログラマの思索 SIerの俺様フレームワークは最悪に激しく同意: プログラマの思索 【1】ソフトウェア再利用の概念としては、ホワイトボックス再利用、ブラックボックス再利用の2種類の区別がある。 ブラックボックス再利用とは、再利用資産を変更なしでその まま利用する。 よくある例は、GUIコンポーネントや数値演算ライブラリなど。 例えば、DLL、Jar、Exeなどのバイナリの実行ファイルが相当するだろう。 ホワイトボックス再利用とは、
アジャイルAPI設計時代の到来！？APIデザインの極意を読みました。 - シスアーキ in はてな
「プログラミング言語Java」「Effective Java」などの翻訳で有名な、柴田芳樹さんの新たな訳書である「APIデザインの極意」を読みました。 APIデザインの極意 Java/NetBeansアーキテクト探究ノート 作者: Jaroslav Tulach,柴田芳樹 出版社/メーカー: インプレスジャパン 発売日: 2014/05/23 メディア: 単行本（ソフトカバー） この商品を含むブログ (4件) を見る 「APIデザインの極意」は、NetBeansの生みの親で、初期のアーキテクトであるJaroslav Tulach（ヤロスラフ・ツゥラッハ）が著者で、NetBeansの開発で得た経験や教訓を纏めたノートが元になって書かれた書籍です。 従来のデザインパターンでは解決できない、後方互換性を維持しながらライブラリを発展させる設計手法について書かれています。 読んだ感想としては、GoF
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Move fast, don't break your API
[REST] 認証が必要な API を REST っぽく作るときのメモ - それはBooks
Hypermedia: The Missing Element to Building Adaptable Web APIs in Rails
