Application Load Testing Tools for API Endpoints with loader.ioSimple Cloud-based LOAD TESTING Loader.io is a FREE load testing service that allows you to stress test your web-apps & apis with thousands of concurrent connections.
APIの気軽な調査をするのにhttpieというツールもあった - $shibayu36->blog;
curlとjqで簡単にAPIの調査をする - $shibayu36->blog; 昨日こんなかんじで、curlとjqを使ってAPIの調査を簡単にするというのを書いたけど、curlの代替品としてhttpieも便利そうだったので自分の備忘録にメモ。brewでインストールできるようだった。 特徴としては curlよりも簡単にJSONでデータをPOSTしたり出来る curlよりもオプションがわかりやすい 出力が見やすく表示される などがありそう。JSONの出力を更にjqのように制御する方法はよくわからなかったのでそういう時は以下のようにjqと組み合わせると良さそう。 $ http --body 'https://api.trello.com/1/boards/4d5ea62fd76aa1136000000c/cards' | jq '.[0:5] | .[] | {name}' { "name":
curlとjqで簡単にAPIの調査をする - $shibayu36->blog;
ちょっとAPIを調査したいと思った時に、スクリプトを書くのも面倒なのでcurlとjqとかを利用してみたら、便利だったのでメモ。今回はTrelloをちょっといじってみた。 Redirecter ひとまずcurlでjsonを出す これは普通にcurlするだけ。 curl 'https://api.trello.com/1/boards/4d5ea62fd76aa1136000000c/cards'これでは見づらい。 curlで出たjsonをpretty化する jqに通すだけでpretty化と更に色付けされる。 curl 'https://api.trello.com/1/boards/4d5ea62fd76aa1136000000c/cards' | jq '.' curlで出たjsonの一部だけ表示する jqはjsonをいろいろ絞り込み出来る。 例えばリストの5件目まで表示。 curl 'h
HerokuのHTTP API設計ガイド
HerokuのAPIチームの一員、Wesley Beary氏がHTTP+JSON API作成のためのガイドラインを要約した形でまとめた。 これは一般的な推奨からはじまっている。 API呼び出しはすべてTLSを使う必要がある。非TLSの呼び出しには403 Forbiddenを返す。 APIには必ずバージョンを付けること。バージョンの指定にはAcceptヘッダを使う。デフォルトバージョンに頼る代わりに、クライアントはAPIバージョンを指定する必要がある。 リソースのキャッシングをサポートするために、ETagヘッダを使うこと。 X-Request-IDの付いたレスポンスを識別すること。これはログやデバッグに役立つ。 大きなレスポンスを扱うために、Range、Content-Range、Next-Rangeを使うこと。 リクエストについて、次のように述べている。 以下のような適切なステータスコード
RESTが日本で受け入れられていった頃の話( #mozaicfm の補足) - Kentaro Kuribayashi's blog
mozaic.fm第7話のRESTの話で、RESTが日本で広く受け入れられていった頃、というか、その端緒の頃の話が出ていて懐かしかったのだし、細部にやや不正確なところがあるのが気になったりもしたので、補足を書いておきますね。 まず、いわずとしれた@yoheiさんがRESTをまず知ったのが2003年とかそれぐらいの時期とおっしゃっていて、それから数年経ち、RESTがWebエンジニアに広く受け入れられていったのは、2007年末にリリースされ、resourcesという機能を取り入れたRails2からというのは、@t_wadaさんがおっしゃっている通り、事実だろうと思います。 また、Podcastの中では、主催のJxckさんが、それはそれと認めた上で、彼自身にとってはAjaxの登場が大きかったということを述べた上で、@yoheiさんの主催された第八回XML開発者の日での高橋征義さんとid:seco
Yoで学ぶはじめてのAPI開発 - pblog
Yoしてますか。 どうやら、Yo APIとやらがある模様。遊んでみます。Yoされたら、ツイッターでやぁするやつを作ってみます。 #ちょっと何言ってんのか 今回は、YAHYAHWORKSにYoすると、@yahyahworks がナンカ言うやつを作ります。 heroku アプリケーションを作成 heroku create ppworks-yo 悲しい事故が起きないようにremoteの名前を変えておく。 git remote rename heroku ppworks-yo これは、複数のherokuアプリケーションを管理していることを考慮して 間違えて別のローカルリポジトリから意図せずherokuにpushしてしまう ことを防ぐためです。git push heroku master でリリースできるのは便利なのですが、herokuのどのアプリケーションにdeployしようとしているかのコンテキ
Develop with Docker Engine API
Reference documentation CLI reference docker (base command)docker build docker builder docker builderdocker builder builddocker builder prune docker buildx docker buildxdocker buildx bakedocker buildx builddocker buildx createdocker buildx debugdocker buildx debug builddocker buildx dudocker buildx imagetoolsdocker buildx imagetools createdocker buildx imagetools inspectdocker buildx inspectdocker
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リク
You don't need API version 2 - yohei's diary
周回遅れ感が半端ないけどバージョニング関連で色々読んで・聞いて思ったことを書く。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight Kazuho's Weblog: 拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima) rest - Best practices for API versioning? - Stack Overflow RESTfulなサービスのバージョンングから得られた知見 RESTとバージョニング 基本的にいわゆる狭義のRESTとAPIのバージョニングは何も関係ない。強いて言えば、HATEOASはバージョニングにも使えるよ、というのがREST信者の主張であるものの、それが正しい（というか実用的）かど
NUCON 資料を公開しました！ | 株式会社ヌーラボ(Nulab inc.)
昨日は雪が舞う悪天候にも関わらず、大勢の方に NUCON にお越し頂きました。みなさま本当にありがとうございました！ 基調講演は元より各セッションも大盛況で、「どのセッションを見ればよいか悩んだ」「見れなかったほうのセッションの資料をみたい」といったお声もいただきましたので、以下に資料を公開いたしました。 テクニカルトラック 開発者がかたるヌーラボのコラボレーションサービス API 最前線 ( ヌーラボ 染田貴志、中原正二、後藤幸 ) 職人任せにしないインフラ構築/運用 ~ DevOps時代を生きぬくために ~ ( ヌーラボ 中村知成 ) 今どきのリアルタイムコラボレーションツールの作り方〜Backlog、Cacoo、Typetalkにおける実践例〜 ( ヌーラボ 縣俊貴 ) ジェネラルトラック ヌーラボサービスの利用事例 – Backlogを使ったオフショア開発 ( EVERRISE 古
RailsのRESTful APIをテストで理解する - ワザノバ | wazanova
http://www.commandercoriander.net/blog/2014/01/04/test-driving-a-json-api-in-rails1 comment | 0 pointsPivotal LabsのEno ComptonがRailsでJSON APIをテスト形式で理解できるように紹介してくれてます。「Railsアプリをてがけると、いずれ、シングルページアプリ、モバイルクライアントのためにRESTful APIが必要になるだろうから練習用に。」ということで、コードはGithubで公開されています。 GET /movies POST /movies GET /movies/:id PUT /movies/:id DELETE /movies/:id 上記のrouteをサポートするために、Railsアプリ + RSpec + FactoryGirlを用意したら、
Autodoc - r7kamura blog
闇Advent Calendar 1日目の記事として、最近の開発における心の闇に触れます。 最近開発した Autodoc というツールについて簡単に説明した後、 この手のツールの開発にあたって考えていた、 創作活動の在り方や、社会の斥力、25歳定年説などについて触れようと思います。 Autodocとは Rack applicationで実装されたAPIに対して、RSpecで書かれたテストを元にAPIドキュメントを生成するもの。 テストを実行すると、テスト中に発行したリクエストやレスポンス、そのテストに付けられたメッセージを元に、 良い感じに情報をまとめ、Markdown形式でAPIドキュメントを記したファイルを生成してくれる。 例えばGitHubではMarkdownファイルを適当に描画してくれるので、 下図のようにGitHub上で簡単にドキュメントを閲覧出来るようになる。 テストの書き方
Ruby から GitHub の API (v3) を叩くサンプルコード (Basic 認証) - ひだまりソケットは壊れない
先輩が GitHub のチームにユーザーを 50 人ぐらい追加しようとしていたので、API 叩いたら楽だろうなー、と思って GitHub の API を叩く方法を調べてみた。 GitHub API v3 OAuth とか使わないといけなくて面倒な感じなのかなーと思ってたけど、Basic 認証を使わせてくれるので結構気軽に API を叩ける感じだった。 手での登録が速かったので API 叩くコードの出番はなかったけど、そのうち使う機会もあるだろうので、Ruby で API を叩くサンプルコードを置いておく。 以下は、1 つのプロジェクトに 2 つの issue を登録するというもの。 require 'json' require 'net/https' GITHUB_USERNAME = 'YOUR_USERNAME' GITHUB_PASSWORD = 'YOUR_PASSWORD' ht
日本の全エンジニアに捧ぐ！現在公開されているAPI一覧【2013年版】 | Find Job ! Startup
2013年のいま、API界隈が熱い！ 今年に入り、官公庁の統計データやNHKの番組情報など、今までなかなか利用できなかったデータがAPIとして扱えるようになってきました。このエントリでは現在公開されているAPIを一覧でまとめます。いま使えるAPIはこれだけ読めば大丈夫。2013年の最新マッシュアップ事情をあますとこなく網羅します！ HOT! API 総務省 次世代統計利用システム（国勢調査、人口推計、就業構造、企業統計、物価統計 etc.） NHK番組表（※未公開） 行政・自治体・公共サービス 郵便番号 郵便番号検索API（郵便番号 → 住所） 郵便専門ネット（郵便番号 → 住所、郵便番号の簡易存在チェック） ぽすたん（郵便番号 → 住所、住所 → 郵便番号） IW3 PROJECT（郵便番号 → 住所、住所 → 郵便番号） 宇宙 Google+ JAXA PR（※現在一部の学生に限定公開
RESTful APIとWebサイトを１つのアプリケーションで作る - リア充爆発日記
RailsでWEB APIサーバを作るときのアーキテクチャをどうするか考えるの続き。 routingなど具体的にどうRailsに盛り込んでいくかの巻。 前提 ログとかをサイトとAPIと分けたいので、API側はサブドメインを切る。twitterみたいにapi.example.com的な。 スマホアプリからのアクセスを考えると、APIの仕様が変わっても後方互換できるようにバージョンを切る。api.example.com/v1的な レスポンスはjsonオンリー とりあえずテスト テストしたいのは・・・ API側はapi.example.comからのアクセスしか受け付けないようになっていること。 何もしないとアプリは１つなので、example.comからも叩けちゃう。問題切り分けとかのときにややこしくならないように。 Jsonフォーマットでレスポンスが返ってくること user_api_spec.r
TechCrunch | Startup and Technology News
When Alex Ewing was a kid growing up in Purcell, Oklahoma, he knew how close he was to home based on which billboards he could see out the car window.…
10分で理解する初めてのAPI
10分で理解する初めてのAPIとは 公開APIに興味を持っている人はどれくらいいるのか？にも書いたとおり、公開APIに興味を持っている人は少なからずいると思います。では、なぜ実際に公開APIを利用したサイトを作ってみないのかというと、公開APIを利用したサイトが完成するまでの流れにも書いたように、実際にサイトを作るまでにはいろいろな壁があるからです。 というわけで、今回は少しでも公開APIに対する抵抗感を取り除いてもらうために、「10分で理解する初めてのAPI」ページを作ってみました。「本当に10分で理解できるのか？」と疑問を持たれてしまいそうですが、「公開APIを利用するのは、怖い、難しい、大変なことではない」ということを理解していただけたら幸いです。サンプルソースとしてはPHP5を使わせてもらいましたが、基本的にはどのプログラミング（スクリプト）言語を用いても大丈夫なはずです。公開AP
API設計に関する10のワーストプラクティス
過半数の開発者が平均で3つ以上のAPIのインテグレーションを実装していると言われている昨今、「使い辛い設計のAPI」を実装するのは開発者にとっては頭の痛い問題ではないでしょうか？ Programable Web上に投稿されたAPIのワーストプラクティスに関する記事が国内外の開発者の目に止まったようです。この記事によると悪いAPIに見られるプラクティスは下記のようなものだそうです。 貧弱なエラーハンドリング HTTPのルールを無視したREST API 裏に潜んだ生のデータモデルの露出 セキュリティの複雑さ ドキュメント化されていない予期せぬリリース 貧弱なデベロッパエクスペリエンス MVCフレームワークが良いAPIにしてくれるという思い込み 開発すれば使ってもらえると見なすこと 不十分なサポート 貧弱なドキュメンテーション APIを利用するだけでなく、APIを提供する場合に上記のようなポイン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
大規模分散システム ”Amazon Web Services” の使い方
http://blog.inouetakuya.info/entry/2013/10/20/132928
