2016/10/12 社内勉強会で使ったスライドを社外向けに一部加筆訂正したもの
こんにちは丸山@h13i32maruです。 WHATWG Streams APIを少し触ってみたので、そのメモです。 ドキュメント WHATWG Streams このメモはLast Updated 21 January 2015を元に書いた whatwg/streams サンプルやリファレンス実装などがある このメモはcommit 879902を元に書いた Stream APIがブラウザにやってくる @jxckさんがnodeのStream APIと絡めてWHATWGのStreams APIを紹介している 概念 JavaScriptのプログラム中で処理する(大きめな)データの読み書きを統一的に扱うためのインターフェースをStreams APIとしてWHATWGが策定している。例えばXHRで大きなファイルを読み込んだ時にはすべてのデータを読み込んだあとにコールバックが呼ばれる*1。これだと読み
ここ数ヶ月にわたって、WebPayはAPIのエラーにまつわる変更を少しずつ行ってきました。 それに付随してドキュメントも拡張しましたが、変更の背景について十分に説明できていない部分がありました。 この記事では、最近のエラーに関連した変更の背景を紹介し、今後どのようにエラーをハンドルすべきか説明します。 記事の内容は執筆時点のものであり、今後同じようにエラーやAPIの変更を行うことがあります。 変更があっても記事の内容はその時点の内容を保持し、ウェブサイトのドキュメントのみ更新します。 必ずウェブサイトのドキュメントを合わせて参照し、手元で動作確認を行ってください。 エラーはなぜ起きるのか WebPayのAPIは、リクエストされた操作ができなかったときにエラーを返すように設計しています。 可能なかぎりエラーにならないような設計、実装を心がけていますが、エラーは絶対に避けられません。 例えば、
3行で言うと herokuが作ってる prmd を使って、JSON SchemaからAPIドキュメントを出力したよ! スキーマ定義から、GoのAPI実装コードも出力するツールを作ったらめっちゃ捗るよ! Goのバリデーション用のライブラリも作ったよ! 今回作ったものの概要とサンプルコード 概要 以前から、APIを開発する上で、以下のようなことが課題となっていました。 そもそもドキュメント書くのがつらい それもあって、ドキュメントより先にコードが変わってしまう ドキュメントと実装の状況の違いが把握しづらい また、ロジックがそんなに複雑ではないAPIでは、実装の作業は リクエストデータのバリデーション 出力データの整形 (フィルタリング) の2つの作業が大きな割合を占めます。 APIの定義ファイルからドキュメントと、バリデーションや出力データ整形のコードを自動生成できれば、大幅に効率が上がると思
Update: Thanks to everyone who read and commented, you influenced the direction of the API. We're going for B, the path-based method, but allowing a header to relax these rules so you can put your worker script wherever you want. Many thanks! With ServiceWorkers you can control requests to any page on your origin, and any of the subresource requests made by those pages. You can completely change w
Stripeの決済サービスの成長は、APIが使いやすいというエンジニアの間での評判がかなり寄与したと記憶しています。 同社のAPIは現在、 エンドポイント: 106 バージョン: 65 APIクライアント: 6 ユーザ企業を煩わせることなく後方互換性をしっかり担保したいという方針を守るための工夫を、Amber Fengが紹介してくれています。 1) ユーザが利用するバージョン情報の把握 ユーザ企業が最初にAPIコールをしたときのバージョン情報をStripe側で保管している。それ以降、ユーザ企業はバージョンのことを意識することなく、最初のバージョンのAPIを利用し続けることができるようにしている。ユーザ企業側でバージョンの変更をしたい場合は、ダッシュボードでの設定や、リクエストヘッダーに情報を付加することで可能。 2) バージョンと機能の整合性 YAMLファイルでバージョンとその振舞いの情報
Today we’re excited to launch an official Hacker News API. We’ve partnered up with Firebase (YC S11) so that the data we’re making available will be near real time, which should be a huge improvement for developers who had to rely on scraping the site for this info. The API is available at https://hacker-news.firebaseio.com/ with some initial documentation and a few examples written by our own Nic
You are here: Home / StrongBlog / Community / Upcoming Breaking C++ API Changes in Node.js v0.12 Editor’s note: Welcome to part three of a three part series that aims to help you get a jumpstart on new and breaking API changes in the upcoming Node v0.12 release. In part one, Alex Gorbatchev pulled out the non-breaking API changes, while in part two he separated out breaking APIs. In part three, Be
ここ数日で広告界を賑わせている?Cookieを使わずにユーザー追跡ができるCanvas Fingerprintingについて軽く説明 概要 従来はCookieを使用してユーザーの追跡を行っていたがCanvas APIを利用した方法でユーザー(正確にはブラウザ)を判別する。現在これをブロックするプラグインやアドオンを確認できていない(7/26現在) The Web never forgetsによると、研究者たちが調査したAlexaトップ100,000サイトのうち、5.5%以上でCanvas Fingerprintingスクリプトが動作しているため今後更に広がることが予想できる。乗るしかない、このビッグウェーブに 中身 ブラウザのCanvas APIを利用してユーザーには見えないレンダリングされたイメージで判別する。端末ごとによってレンダリングされたイメージは微妙に違うらしい。いわば指紋認証と
追記 RailsでJS辛い問題に関しての結論:http://qiita.com/kaiinui@github/items/dad6180f1910c6a4bfd5 -- 近年、(1) Web/App両対応が増えてきたこと、(2) WebでもJSを多用するようになったこと、の二つがあり、以下の点でRailsが微妙になっている。 ViewのJavascriptがRailsから独立している API層のサポートが微妙 最初に書いておきますが、特に決定的な解決策もなく、辛いから今後解消されてほしいよね、な話です。 ViewのJavascriptがRailsから独立している Railsはとても堅牢。 モデル、コントローラ、ルーティングと、変にいじらない限りはほとんどテストが要らない。 必要なのは、モデルに新たにpublicメソッドを付けたときくらいだろう。 実際、バックエンドはそうそうバグが出ない。
Send feedback Gmail API Overview Stay organized with collections Save and categorize content based on your preferences. The Gmail API is a RESTful API that can be used to access Gmail mailboxes and send mail. For most web applications the Gmail API is the best choice for authorized access to a user's Gmail data and is suitable for various applications, such as: Read-only mail extraction, indexing,
Building a back-end API layer introduces a whole new layer of coordination between server and client code. While there are many aspects to this delicate dance of communication, one key ingredient to minimizing back-and-forth-confusion-about what-call-does-what, is consistently communicating about your API endpoints. This is by no means rocket science, but over time I’ve created a template that I n
The first draft of the service worker spec was published today! It's been a collaborative effort between Google, Samsung, Mozilla and others, and implementations for Chrome and Firefox are being actively developed. Anyone interesting in the web competing with native apps should be excited by this. Update: Is ServiceWorker ready? - track the implementation status across the main browsers. So, what
Natasha Murashevがブログで、API Strategy and Practice Conferenceにおける、Michele Titolo (先月、「 Ruby RoguesメンバとiOSエンジニアのAPI議論」で紹介しました。)とEtsyのPaul Wrightの講演のポイントをまとめてくれています。 1) スピード ユーザは待ってくれない。300msで、リクエスト / レスポンスの処理 / ユーザに結果の表示をする。 2) RESTが常にベストとは限らない 以前のEtsyのAPIリソースはDBスキーマのミラーになっていた。クライアントがリスティングのリストを受け取ったら、ユーザがFavoritedに指定しているリスティングIDを取得するために、再度APIコールする必要があった。クライアントのAPIコールが増えると、クライアントのスピードが落ちる。また障害の可能性となるポ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く