タグ

apiに関するakishin999のブックマーク (491)

  • WebAPIリクエスト仕様書としてcurlコマンドのご提案 - Qiita

    WebAPIの仕様を記述する方法はいくつかあると思う。 普通に日語で記述する JSON Hyper-Schema、WADL、RAML、Swaggerなどを使う 仕様書の代わりにプログラムを書く HTTPメッセージそのものを記述しておく でも、文法にばらつきがあったり、読みにくかったり、ツールのセットアップが面倒だったり、どれもイマイチな所があって、手軽な方法が欲しいと思っていた。 何気なくcurlコマンドのオプションを調べていたら、「もうこれでAPIドキュメント扱いにしちゃえばいいんじゃね?」と思えてきたのでメモしておく。 curlコマンドのおさらい curlコマンドはlibcurlの付属コマンドで、最近のUnix系OSなら大抵最初から入っていると思う。コマンドの詳細はmanを読んでいただければ。 cURL - How To Use (マニュアルページ日語訳) curlコマンドのオプシ

    WebAPIリクエスト仕様書としてcurlコマンドのご提案 - Qiita
  • Rails API 使ってみた - Qiita

    昨日 Ginza.rb 第23回 APIのみのRailsアプリ「Rails API」を読もう! で Ginza.rb に初参加してきたので復習メモ。 ちなみに Ginza.rb は二周年だそうですよ。おめでとうございます! Ginza.rb の内容は Rails5 でとりこまれることが決まって目下議論中らしい Rails API についてのコードリーディングでした。 pull request RAILS API TO BE PART OF RAILS 5 Rails API ginza.rb 23th Rails API まだ Rails 体にマージされていないので、普通の railsrails-api で比較しながら使ってみました。 アプリ作成 $ gem install rails-api $ rails new blog_app # 普通の rails $ rails-api

    Rails API 使ってみた - Qiita
  • 公共クラウドシステム | API公開サイト

    公共クラウドシステムとは 全国の自治体の観光情報をオープンデータとして提供するシステムです。 データを利用いただけましたら、掲載データ利用のご連絡から御一報いただけると幸いです。 新着情報

  • Shibu's Diary: cURL as DSLとは何だったのか。あるいは細かすぎて伝わらないcURL as DSL。

    渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 By Jeremy Brooks under CC BY-NC 先日、cURL as DSLというツールを公開しました。その後、何度も同じような質問を受けたりしたので、ブログにまとめてみます。 なぜこのツールを作ったの? RESTfulというものは大分一般的になってきました。HTTPでAPIを提供というのもよく見かけます。ですが、僕はこのRESTfulというやつが嫌いです。 GETのURLをシェアすればいつでも同じページがある(変な状態を持たない)、みたいな思想はいいんですが、HTTPのAPIはどうも使いにくい。ドキュメントのHTTPのサンプルを見て、ドキュメントをじっくり読み込んで、パラメータをJSONやらXMLで組み立ててボディに乗っけて(しかも大抵パラメータがアホのように

  • RubyでGoogleDrive APIを使用するためにアクセストークンを取得する | tagamidaiki.com

    RubyGoogleDrive Gemを使ってGoogleDriveをさわろうとしたところ、OAuthの認証でつまづいたのでそのメモします。 OAuth2.0の流れはこんな感じです。 ClientIDとClientSecretを発行する 認証する アクセストークンを取得する リフレッシュトークンからアクセストークンを再取得する GoogleDrive gemを使ってみる ClientIDとClientSecretを発行する まずはプロジェクトを作成します。 https://cloud.google.com/console/project APIsから「Drive API」と「Drive SDK」をONにします。 「Credentials」から「CREATE NEW CLIENT ID」から今回のプログラムで使う必要項目を取得します。 以上のような項目を選択 これでClientIDとCli

  • 突然GoogleMaps APIのライセンス費用を請求され 知人の企業のウェブサイトで、Google Maps API v3を 利用しております。…

    突然GoogleMaps APIのライセンス費用を請求され 知人の企業のウェブサイトで、Google Maps API v3を 利用しております。 昨年秋からアクセスが急増して、1日25000回以上のリクエストがありましたが、気づいてなかったそうです。 1ヶ月前にグーグル社員の方から連絡があり、1日25000回を超えていることに ついて、ライセンスを購入するよう打診されたそうです。 年間1100万PVの費用が約1000万円余りの請求で驚いて 急ぎアクセスの多いページのグーグルマップをイラストの地図に差し替えたそうです。 グーグル社員の方にそれを伝えると、25000回を下回ったとしても、 これまでに利用したAPIに関しては遡って費用が発生すると回答があったそうです。 Analyticsを確認すると、1日25000回を超えない日もあり 90日連続して25000回を超えていません。 下記URLの

  • [Apiary]Markdownで始めるAPI開発とAPIドキュメント作成 | DevelopersIO

    APIを作るとき みなさん、毎日API使ってますか?私は、ワンライナーでAPIをコールすることにハマっています。さて、いつも使っているAPIを作る側になったとき、どのように設計していますでしょうか?また、作ったAPIをどのように使ってもらっていますか?そんな疑問に応えるサービスがApiaryです。 Apiaryとは? Apiaryは、REST APIをサクッと書けるサービスです。また、APIドキュメントも生成してくれます。モックサーバも提供してくれます。API利用サンプルコードも作ってくれます。うん、使わないって選択肢は無いですねw。 無料登録すると早速使えるようになります。チームでプライベートなAPI開発をしたければ有料プランを選択してください。 API開発の流れ API開発の流れは、まずはじめにMarkdown形式でドキュメントを書きます。既にサンプルがあるのでこれを使ってみましょう。

    [Apiary]Markdownで始めるAPI開発とAPIドキュメント作成 | DevelopersIO
  • もう終わりだと思う - zowのプログラムな日々

    インターネット黎明期から、いや、インターネット以前からPCを使う人にとってBBSというのは身近な存在だと思う。古くはパソコン通信時代から掲示板というもので世の中のPCユーザは情報を共有してきた。誰もが見れて誰もが書き込める、そんな万人が情報をやり取りするオープンな場をBBSは提供してきた。 たしか2000年頃だったと思うけど、そんなインターネットにある最大の掲示板2ちゃんねる」が閉鎖危機に陥る。余りにも人気がありすぎて、通信量がヤバイことになったからだ。そこで2chのプログラマ有志が集まって通信量削減の為に試行錯誤し始めた(当時のその出来事はフラッシュになってる)。その結果、2chはWebブラウザでなく、2ch専用ブラウザという物で見ようということになり、それが利用者にも浸透し、いまでは専用ブラウザでみるのが当たり前の状態になっている。 その後、10年以上試行錯誤を続け、専用ブラウザの文

    もう終わりだと思う - zowのプログラムな日々
  • ssig33.com - 2ch のアレ

    robots.txt は法律上以下のようになってます。 無視してクロールしてもいいけど、無視してクロールした結果を公開するのはダメ つまり新 2ch では以下のようなサイトが法律上 NG になります API キーをアプリから解析して新 API 勝手に使ったりクロールしたりして過去ログ公開するようなサイト 上記のような仕組みで旧 2ch っぽいインターフェイスを提供するプロキシサイト 上記のような仕組みで動作する Web アプリケーション型 2ch クライアント OK なのは以下の行為です スクレイピングして動作するデスクトップ、携帯電話向けのクライアントを開発、配布する 無論、これらのクライアントが常軌を逸した動作をして、結果 2ch のサービス継続を妨害するようなことがあれば、 2ch は民事、刑事で適切な対応を取ることができるでしょう。この場合参考になるのは librahack 事件

  • 2ちゃんねるがdatを近日廃止、さらにウェブスクレイピングを用いた専用ブラウザ開発・公開は禁止して2015年3月3日以降はAPI経由の許諾制に

    「2015/3/3以降、2ch.net専用ブラウザ(以下「専用ブラウザ」)を開発、公開するには、2ch.netの所有者であるRaceQueen社の許諾を得て、2ch.netが提供するAPI(以下「API」)を用いて開発する必要があります」ということで、developer.2ch.netにて、今後の2ch専ブラ(2ちゃんねる専用ブラウザ)開発について、大きな方針転換が行われることが発表されました。 developer.2ch.net http://developer.2ch.net/ まず大きな変更としては2ちゃんねるに書き込まれたレスが保存されているdatの直読みを廃止し、API方式へ移行するということ。この許諾は誰がするのかというと、RaceQueen社。あともうひとつ、JaneStyleの開発元でもある株式会社ジェーンもRaceQueen社からAPIの使用許諾を得ており、しかも「一部の

    2ちゃんねるがdatを近日廃止、さらにウェブスクレイピングを用いた専用ブラウザ開発・公開は禁止して2015年3月3日以降はAPI経由の許諾制に
  • 「チーム開発に役立つstubcell」ってタイトルでCodeGrid 2周年パーティでLTしてきた。 - from scratch

    CodeGrid 2周年パーティでLTしてきました。 2周年おめでとうございます!! TL;DR stubcellというjsonを返すことに特化したstubサーバーを作りました 内部的にjson5を使うことで定義ファイルにコメントを書くことができ、開発者間のコミュニケーションの補助になる grunt, gulpからstubサーバーを使うことができるため、フロントエンドタスクランナーと相性が良い 発表資料 stubcell 概要 いわゆるJSONを返すことに特化したstubサーバーです。 チームで開発する時に、APIサーバー、クライアントサイド、websocketサーバーといった感じに複数の役割を複数の人数で請け負って同時並行開発することが多く、APIのエンドポイントがなくてもクライアントサイドやwebsocketでも開発できるようにするためにstubcellを作りました*1。 また複数人で

    「チーム開発に役立つstubcell」ってタイトルでCodeGrid 2周年パーティでLTしてきた。 - from scratch
  • RESTのベストプラクティス | POSTD

    現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR

    RESTのベストプラクティス | POSTD
  • 【Rails】RSpecと三種の神器でらくちんWeb APIテスト - Qiita

    はじめに 3月頃,『【Rails】RSpecでWeb APIのテストでハマったところ①』という初心者丸出しな記事を書きました. あれから9ヶ月ほど,お仕事としてRailsに触れたりしたため知見・スキルも向上してきたと思います. そして今,前述の記事を見直したところ恥ずかしくて顔を覆いたくなる感じになったので改めてWeb APIのテストについて書いていきます. APIのテスト? そもそもWeb APIのテストはどこに書くの?ってところからですが… Controller SpecではなくRequest Specに書いていきます. Use RSpec Request Specs Since we’ve established that we’ll be using Rack::Test to drive the tests, RSpec request specs make the most s

    【Rails】RSpecと三種の神器でらくちんWeb APIテスト - Qiita
  • Web API The Good Partsを読んで覚えておきたい所メモ – morizotter blog

  • Web API用の負荷テストツールで遊んでみる - memorandum

    これはWeb API Advent Calendar 2014の16日目の記事です。 はじめに Web API Advent Calendar 2014 8日目ではkazuchikaさんよりApigee製のAPI負荷ツールapibの紹介がありました。 この記事ではapibに加えてBoomというGolang製の類似ツールを簡単に紹介し、様々なマイクロWebフレームワークに対して両者を使ってみます。 Boom rakyll / boom Python製のAPI負荷テストツールBoomをGo言語に移植したもの Googleエンジニアが開発 Apache Bench(ab)と同じくリクエスト回数を指定した計測 レスポンス時間がヒストグラム表示される ソースコードがコンパクト インストール Golang環境がセットアップされているものとします。 go get github.com/rakyll/bo

    Web API用の負荷テストツールで遊んでみる - memorandum
  • RESTful Web API 開発をささえる Garage (client 編) - クックパッド開発者ブログ

    料理動画事業室の @yoshiori です。前に「RESTful Web API 開発をささえる Garage」で紹介した RESTful Web API を開発する Garage のクライアント側のライブラリを公開しました。この記事ではその使い方を紹介したいと思います。Garage の設計思想やサーバ側の実装については上記記事を御覧ください。 今回は簡単にクライアント側の挙動を知っていただくために pry を使って説明したいと思います。 アクセスするサーバは先程の記事で作成したアプリケーションを使用してみます。 サーバの準備 https://github.com/taiki45/garage-example の README にも書いてありますので簡単に進めたいと思います。 まずは下準備としてコードを github から clone してきて、ライブラリのインストールと DB のマイグレ

    RESTful Web API 開発をささえる Garage (client 編) - クックパッド開発者ブログ
  • アナログ世界時計をチャットに貼れるサービス Tokei.link をリリース(Slack 対応) - @kyanny's blog

    「現在時刻を知りたい国や都市をチャットでつぶやいたら時計が表示されると便利だな」と思ってそういうサービスを作りました。無料です。登録も不要です。 http://www.tokei.link/ アナログ時計なので文字を読まずにパッと見でだいたいの時刻を把握できます。一つの国や都市の現地時刻を表示する機能と、二つの国や都市の現地時刻を並べて表示する機能があります。「ロンドンとシンガポールの同僚とビデオ会議をしたいけど、いま何時かな?」みたいなときに便利です。 API があります http://www.tokei.link/doc http://www.tokei.link/png?destination_timezone=New+York&local_timezone=London のような URL に GET リクエストを送ると、指定したタイムゾーンの現在時刻を表す PNG 画像を返します。

    アナログ世界時計をチャットに貼れるサービス Tokei.link をリリース(Slack 対応) - @kyanny's blog
  • APIのエラーハンドリングを見直そう - WebPay Engineering Blog

    ここ数ヶ月にわたって、WebPayはAPIのエラーにまつわる変更を少しずつ行ってきました。 それに付随してドキュメントも拡張しましたが、変更の背景について十分に説明できていない部分がありました。 この記事では、最近のエラーに関連した変更の背景を紹介し、今後どのようにエラーをハンドルすべきか説明します。 記事の内容は執筆時点のものであり、今後同じようにエラーやAPIの変更を行うことがあります。 変更があっても記事の内容はその時点の内容を保持し、ウェブサイトのドキュメントのみ更新します。 必ずウェブサイトのドキュメントを合わせて参照し、手元で動作確認を行ってください。 エラーはなぜ起きるのか WebPayのAPIは、リクエストされた操作ができなかったときにエラーを返すように設計しています。 可能なかぎりエラーにならないような設計、実装を心がけていますが、エラーは絶対に避けられません。 例えば、

  • REST APIドキュメント生成パターン - ✘╹◡╹✘

    REST API用のドキュメントを生成するときにどうやってるかについて雑記を残しとく。 概要 実装とドキュメントの乖離を避けるためには、同じ意味情報を二箇所以上に定義することを避ける必要がある。そのための方法として、実装それ自身か、もしくは実装が参照している何らかのメタデータを元にしてドキュメントを生成したり、テストの実行結果からドキュメントを生成するというパターンがある。 テストから Cookpadでは、autodocというライブラリを利用して、RSpecでテストを実行している途中で得られたメタデータからドキュメントを生成している。これはテストの実行結果からドキュメントを生成するパターン。 これは実現方法としてはかなり特殊な部類。このパターンが最も効果的に働くのは、ドキュメント生成のために余分な開発コストはあまり掛けたくないが、テストは真面目に書いている OR 真面目に書いてほしい、とい

    REST APIドキュメント生成パターン - ✘╹◡╹✘
  • じんもんそんで使えそうなデータやAPI等のリスト | Digital Humanities notes in Japan

    以下、とりあえずとってきて色々いじることができそうで、人文学研究に役立ちそうなデータをリストします。(by 永崎研宣) 日編 近代語のコーパス(国立国語研究所) http://www.ninjal.ac.jp/corpus_center/cmj/ コーパス開発センター(国立国語研究所)-近代文語Unidic、中古Unidic等もあり http://www.ninjal.ac.jp/corpus_center/ 参考: オープンソースの日形態素解析エンジンMecab https://code.google.com/p/mecab/ オックスフォード上代日語コーパス http://vsarpj.orinst.ox.ac.uk/corpus/ 日語テキストイニシアチブ http://jti.lib.virginia.edu/japanese/index.euc.html 青空文庫 ht