日本の行政機関等が公開しているAPIについてのまとめ（2016年8月17日暫定版。随時更新） - Qiita
この記事は下記のURLにあるコミックマーケット90で頒布した同人誌と自分が管理するブログの記事を微修正し、転載したものです。 南関東開発機構 : 同人誌「日本の行政機関が公開中のAPIについて調べてみた本」を公開しました http://blog.livedoor.jp/south_kanto_dm/archives/52143201.html 南関東開発機構 : 日本の行政機関が公開中のAPIについてのまとめ（2016年8月17日暫定版） http://blog.livedoor.jp/south_kanto_dm/archives/52143463.html 前書き この記事の目的は、日本の行政機関等が公開しているAPIを紹介する事です。 日本の情報技術は他国と比較して、立ち遅れている部分があり、これを立て直すのが喫緊の課題であると言えます。 日本政府もこの問題に危機意識を持ち、先日、経
面倒な手続き不要！「Web API」の超お手軽活用術をJavaScriptコード付きで一挙大公開！ - paiza times
どうも、まさとらん（@0310lan）です。 今回は、面倒な登録手続きやトークンなどが一切不要で、今すぐ利用できる便利な「Web API」を厳選してご紹介しようと思います。 これらのAPIを使うことで、Web制作がちょっと便利になったり、独自性のあるユニークなサービスを構築できるようになるでしょう。 また、簡単に扱えることから、「Web APIを使って何か作ってみたい…」と思っている初心者の方にもオススメですよ！ ■「Web API」の使い方！ 今回ご紹介する「API」は、いずれも「JSONP」形式でデータが取得できるので、普通のJavaScriptだけで試すことが出来ます。 以下のコードを、HTMLファイルに記述するか、新規にJSファイルを作って読み込むようにしましょう。 var script = document.createElement('script'); script.src
翻訳: WebAPI 設計のベストプラクティス - Qiita
これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公
僕が考えた最強のAPIドキュメント生成 - 銀の人のメモ帳
2023 追記 2023 年現在では、以下の文章では採用を見送っている OpenAPI を使えば OK という雰囲気です。 Web APIの設計 作者:Arnaud Lauret翔泳社Amazon TL; DR ドキュメント生成にはkevinrenskers/raml2htmlを使った ドキュメントはRAML - RESTful API modeling languageで書いた RAMLにはJSON SchemaとJSONを記載できる APIで返ってくるJSONはRailsアプリのrequest specでJSON Schemaを使ってテストした JSON Schemaはr7kamura/json_worldで生成した ドキュメントに載せる例示のJSONもJSON Schemaからgin0606/screijiを使って生成した 上記の方法だとリクエストパラメタとドキュメントの整合性を担保
APIデザインケーススタディ —— Rubyライブラリを移植する前に読む本 - 世界線航跡蔵
『 APIデザインケーススタディ 』という本を頂戴したので読んでみた。 ライブラリ作者に向けて この本はRuby標準ライブラリを題材にして、分かりやすく、多様な機能をサポートして、互換性を保つAPIの設計をするにはどのように考えるべきかを教えてくれる。 ここでAPIと言っているのは、一般的なRubyのクラスとオブジェクトとメソッドから成るライブラリをどうデザインするか、という話である。 別にChef RecipeやRSpec DSLのようなちょっと変わったDSLを設計するとかそういう話ではない。確かにその種の言語内DSLのデザインには固有のセンスが必要とされるし、 Ruby DSL Handbook なんて本が書かれているように実装にあたってもある種のテクニックが必要なのも確かだ。でも、それ以外の「ふつう」のライブラリのデザインは果たして簡単だろうか。 適切な粒度のクラスを定義する。必要な
RailsでAPI開発する前に知っておくべき４つのこと - Qiita
$ bin/rails g scaffold user name:string mail:string password:string invoke active_record create db/migrate/20151214145437_create_users.rb create app/models/user.rb invoke test_unit create test/models/user_test.rb create test/fixtures/users.yml invoke api_resource_route route resources :users, except: [:new, :edit] invoke scaffold_controller create app/controllers/users_controller.rb invoke test_un
Swaggerで始めるモデルファーストなAPI開発
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
Geocoding API overview | Google for Developers
Send feedback Geocoding API overview Stay organized with collections Save and categorize content based on your preferences. The Geocoding API is a service that accepts a place as an address, latitude and longitude coordinates, or Place ID. It converts the address into latitude and longitude coordinates and a Place ID, or converts latitude and longitude coordinates or a Place ID into an address. Wh
APIドキュメントを支える技術 - Qiita
最近のウェブ開発では各機能ごとをAPIでつなぎ込む時代になっています。 そのため、各チームが開発をしていく上で、 他のチームにAPIの仕様を伝える方法をきちんとまとめておく必要が出てきています。 そんな中でAPIドキュメントにどのような役割が求められていて どのような選択肢があるか、一旦自分の把握している知識をまとめています。 (ここで書いているAPIは、httpでアクセスしたら、JSON形式でレスポンスを返すウェブサービスのAPIを指しています) APIドキュメントを用意する上で、すぐにぶつかる壁 APIドキュメントを用意する場合に、何も考えずにExcelやwikiにまとめると、早い段階で メンテナンスのコスト の問題にぶつかります。 『APIドキュメントを書く時間がない』 『本当にドキュメント通りの結果が返ってくるか、試してみないとわからない』 『実際に返ってくるAPIとレスポンスが違
WebAPIでエラーをどう表現すべき？15のサービスを調査してみた - Qiita
2017-01-05 追記 2016年3月にエラーの標準形式RFC7807「Problem Details for HTTP APIs」が提案され、今日現在proposed standard(標準化への提唱)となっています。こちらも是非ご覧ください。 RFC 7807 - Problem Details for HTTP APIs HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様 最近はREST APIを提供しているサービスが増えてきていますね！また公開されるAPIだけでなく、Microservicesなアーキテクチャを採用して、バックエンドがWeb APIで通信するケースも増えてきているように思います。 APIを使うときはあまり気にしたこともなかったですが、いざAPIを設計してみるとどんなインターフェイスがいいのか、どんな形式がいいのかといった疑問が次々と出てきます。
APIembed by Kong
Customizing Your Widget Widget Anatomy <iframe src="//api.apiembed.com/?source=https://apiembed.com/sample.json&targets=all frameborder="0" scrolling="no" width="100%" height="350" seamless></iframe> api.apiembed.com The API root, available in both HTTP and HTTPS flavors. source Source URL, a HAR Request object as the http request description format targets An ordered comma separated list of all t
JSON Schema で Web API のスキマを埋めよう
クライアント実装 サーバ実装 仕様 Web API にありがちなこと API ドキュメント リクエスト レスポンス ぶっちゃけAPI の追加時く らいしか更新していない なぜかドキュメントにない属性が 含まれている 手が滑ってドキュメントと若干違う形式の 属性を含めちゃったけどなんとなく通った クライアント実装 サーバ実装 仕様 いまは API Blueprint で頑張ってる (http://apiblueprint.org/) API ドキュメント リクエスト レスポンス Markdown の スーパーセット (ツラい) API Blueprint (YAML 表現) generate mock validate あんまり嬉しく ない なんか別に JSON Schema 書かない といけない クライアント実装 サーバ実装 仕様 今日話したいこと JSON Schema API ドキ
REST APIドキュメント作成ツールはapiary.ioが決定版かもしれない - Qiita
背景 APIドキュメントを書くのが楽になるツールまとめ - Qiita iodocsで便利なREST APIドキュメントを作成する - Qiita これまでずっとREST APIドキュメントをwiki上で管理していて、重たいページ上で特殊記法使ったり、スタイルの調整に時間を取られるのが辛かった。そこで良さげなドキュメントツールを色々調べてたんだけど、最終的にapiary.ioが一番良さそうという結論になってきた。 このサービスの主な特徴。 markdown記法でAPIドキュメントを記述できる ドキュメントの生成と同時にAPIのモックサーバを用意してくれる サインアップから5分くらいあればドキュメント公開できる。ドキュメントのホスト先を気にしなくてもいい。 特にドキュメントと一緒にモックを作ってくれるのは他にはないポイントでかなり便利。 使ってみる サインアップはGithubアカウントで h
これだけ押さえておけばあらゆるAPIを呼び出せる！ Google APIを使用するための基本
対象読者 GoogleのサービスやAPIに興味のある方、悩んだことがある方 Google Cloud Platformに興味のある方 GoogleではないAPIの経験がある方（推奨） 必要な環境 Googleアカウント Webブラウザ サンプルコードを実行する場合は、Javaの開発環境 Google APIの基礎知識 Googleが提供する大抵のプラットフォームやサービスは、それらのリソースへアクセスするためのAPI（以下、Google API）を提供しています。まずは、Google APIを理解するための基礎となる事項を押さえておきましょう。 APIとの通信方式とDiscovery Document Google APIと通信する方式には次の2つがあります。 OAuth1でアクセス許可を得て、ATOM書式で通信する OAuth2でアクセス許可を得て、JSON書式でhttpsを使って通信す
リトライと冪等性のデザインパターン - Blog by Sadayuki Furuhashi
リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の３つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から： なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ
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リク
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Not Found
Firefox Platform Status
Heroku HTTP API Design Guide
Tumblr APIでwebサービスを作りたい全ての人に向けて書きました
