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を設計してみるとどんなインターフェイスがいいのか、どんな形式がいいのかといった疑問が次々と出てきます。
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新記事 次号にまとめられます。 Kaigi on Rails 2025 開催レポート mruby Girls Matsue 1st 開催レポート 書籍紹介『シンプリシティ―持続可能かつ人間的で効果的なソフトウェア開発』 RegionalRubyKaigi レポート (93) ながらRuby会議01 RegionalRubyKaigi レポート (92) 北陸 Ruby 会議 01 レポート RegionalRubyKaigi レポート (91) Toky
内部用APIであるか外部の開発者向けのAPIであるかに関わらず、ドキュメントと実装との乖離は極力避けたいものであるが、注意深く開発を進めない限りこの状況は容易に起こり得る。何が乖離を引き起こし、どうすればこの状況を回避できるのか考えながら、JSON Schemaの利用例を紹介する。なおこの投稿では、HTTP経由でデータの通信を行うような狭義のAPIのことをAPIと呼ぶことにする。 同じ情報源を参照する APIドキュメントと実装が同じ情報源を参照するようにすれば、論理的に関連した要素は統一的に変更され、これらの変更は完全に同期が取れたものになる。つまり、変更時に乖離が生じにくくなる。但し情報の見せ方によって乖離が発生する可能性は十分にだろうし、乖離が発生するのは理解しようとする側の認識の問題であるから、論理的に全く起こり得ないということではない。 この参照の形には、両者が別の情報源を参照する
Do not use verbs: /getAllCars /createNewCar /deleteAllRedCars 2. GET method and query parameters should not alter the state Use PUT, POST and DELETE methods instead of the GET method to alter the state. Do not use GET for state changes: GET /users/711?activate or GET /users/711/activate 3. Use plural nouns Do not mix up singular and plural nouns. Keep it simple and use only plural nouns for all r
Herokuが自ら実践しているAPIデザインガイドをGithubに公開した． “HTTP API Design Guide” このガイドは些細なデザイン上の議論を避けて，ビジネスロジックに集中すること目的としている．Heroku特有なものではなく，一般にも十分適用できる知見となっている． 最近は，モバイル向けにAPIをつくることも多いため，勉強もかねて抄訳した．なお内容は，HTTP+JSONのAPIについて基本的な知識があることが前提となっている． 適切なステータスコードを返す それぞれのレスポンスは適切なHTTPステータスコード返すこと．例えば，“成功"を示すステータスコードは以下に従う． 200: GETやDELETE，PATCHリクエストが成功し，同時に処理が完了した場合 201: POSTリクエストが成功し，同時に処理が完了した場合 202: POSTやDELETE，PATCHリク
TL;DR JSON Schemaを使ってこういうことが実現可能になった。 ダミーAPIサーバの提供 ドキュメントの自動生成 APIクライアントの動的定義 APIサーバのバリデータの動的定義 APIサーバのレスポンスの自動テスト JSON Schemaとは JSON SchemaというのはあるJSONのデータ構造を記述するための方法および書式の仕様で、 JSON SchemaもJSONで記述される。 これを利用すれば、リソースベースの(=RESTfulライクな)APIの仕様が簡便に記述できる。 例えば、我々のAPIはレシピとユーザというリソースを扱っていて、 それぞれCRUDのAPIを備えており、レシピはidとtitleとdescriptionという属性を持つ、 という旨をJSON Schemaで表現できる。 なんで最近ちょっと流行ってんの Mobile First、 Service Or
移転しました http://please-sleep.cou929.nu/20130121.html
HTTPでアクセスして、JSONを返すようなWebサーバを書きたいとする。 どんな言語を選ぶか。どんなミドルウェアを選ぶか。どんなライブラリを選ぶか。 たとえば、TIOBE Softwareが公表している「Programming Community Index(PCI)」という指標がある。人気のあるプログラミング言語の数値化。これを見ていて思ったのは、「多すぎだよね、プログラミング言語」ということ。これらのうち、どの言語を勉強し、どの言語をプロジェクトに採用すべきなのか。 その感触を得るために、 「同じ仕様のREST serviceを複数言語で実装したらいいんじゃね？」 と思った。いくつかの言語で実装を起こしてみている。 前提条件 大規模な開発を想定する。ユーザの規模が大規模。トランザクション数が大規模。そして、開発者が大規模。 実用的かつモダンな開発を想定する。プロジェクト毎のバージョン
yohei-y:weblog: HTTP ステータスコードを正しく使おう
先月、ぐるなび API がリリースされていました。 ぐるなびさんの持っている膨大なデータベースに Web API を通して気軽にア クセスできるようになったのは、非常に喜ばしいし、その英断に感謝したいと 思います。 しかし、Web API 仕様書、特にエラー仕様を見てちょっとがっかりしました。 もう少し上手にデザインすれば、もっとよかったのに…、という思いです。 一度出してしまった API はそう簡単に変えられないと思いますが、 参考までに僕だったらどうするか、を書いてみます。 この仕様の一番の問題はエラーコードです。 以下は 2-2 のエラー仕様に記述されているサンプルです。 <?xml version="1.0" encoding="UTF-8"?> <gnavi> <error> <code>602</code> </error> </gnavi> タグが三つ(gnavi, erro
Yahoo!デベロッパーネットワークにテキスト解析APIが登場！ 2007-06-18-1 [WebTool][NLP][MECAPI][Programming] Yahoo!デベロッパーネットワークに「テキスト解析」が登場しました。 第一弾は日本語形態素解析APIです。 ヤフーのいろんなところに使われている WebMA という 形態素解析エンジンのAPIです。 - Yahoo!デベロッパーネットワーク - テキスト解析 - 日本語形態素解析 http://developer.yahoo.co.jp/jlp/MAService/V1/parse.html MECAPI の仕様に似ていますが、まあそういうものです。 (MECAPI https://maapi.net/) で、先日 MECAPI で作った「文で検索」[2007-04-03-1]の WebMA 版を作ってみました。「文で検索2」
Googleから「Google AJAX Feed API」が公開されました。 このAPIは、他ドメインのRSSやAtomの一般的なフィードを簡単に取得するためのAPIです。 公開APIを利用したサンプルサイトを作っていくよ管理人として、早速「Google AJAX Feed API」のテストを兼ねて、[Z]ZAPAブロ～グ2.0に導入してみました。 各記事の下部に、「この記事に言及していそうなブログを検索する」というリンクを追加してあります。 このリンクをクリックすると、画面遷移することなくAjaxで、リンク元のブログが表示されます。 Googleにキャッシュが生成されるため、クロスドメイン制約を気にすることなく、他のドメインのフィードを表示できます。 [Z]ZAPAブロ～グ2.0:人気記事の はじめてのApolloプログラミング ニコニコ動画みたいなものを作ってみるテストと問題点 など
LingrのAPIが公開されましたね。 チュートリアルも公開されていたので、いい加減に翻訳してみました。 かなりシンプル。常駐Botとか簡単に作れそう。 このチュートリアルでは、おおまかなLingr APIの使い方を解説します。詳細についてはAPIリファレンスを参照してください。 ここでは、ニックネームを名乗ってチャットルームに入り、"Hello world"と発言した後、チャットルームから出る、という一連の処理を行います。 なお、curlというHTTPクライアントを使用します。MacOSXや、Linuxの多くのディストリビューションでは標準でインストールされています（Windows用バイナリをKoRoNさんが配布しておられます）。他に用意すべきものはありません。 0. APIキーを取得する Lingr APIを使うにはAPIキーが必要です。ここでゲットしてきてください。 以下のアドレスを
これはすごい・・・Googleの隠れAPI（？）を見つけてしまった人がいます。Web 2.0系でよく使われる角丸用の部品を簡単につくることができちゃいます。 » Zach’s Journal – google’s own cornershop 例えば、Google グループのページの丸角は下記のURLで生成されています。 http://groups-beta.google.com/groups/roundedcorners?c=999999&bc=white&w=4&h=4&a=tr 生成される画像は以下。 そしてご推測のとおり、パラメーターをいじることができちゃいます。たとえば下記のような画像を自由自在です。 以下、パラメーターの詳細です。 c：色を指定します。色の名前（aqua, black, blue, fuchsia, gray, green, lime, maroon, navy
MECAPI (MeCab API) 暫定版を公開 2006-09-18-1 [WebTool][NLP][MECAPI] taku-ku 氏による日本語形態素解析器 MeCab の Web Service を 作ってみたので公開します。その名も MECAPI (メカピ)！ - MECAPI - MeCab Web Service (MeCab API) http://mimitako.net/api/mecapi.cgi Perl の MeCab モジュールを使っています[2006-02-25-4]。 仕様は今後変わっていく可能性あり。 また、サーバ負荷によっては予告なく止めることもあり。 同一 IP からの回数制限とかするかも。 とりあえずしばらく様子を見て、落ち着いたらソースを公開します。 でもって、余裕のあるサーバに置いてもらいたいと思っています。 現段階で、
_ フィード情報におかしな情報が混ざっているものがあります blogmapのOPMLインポートのテストをしていたんだけど、なぜかその機能を使って追加したフィード情報に、おかしな情報が混ざっていることがあります。まだ原因は調査中（ライブラリのアップデートが影響しているかも？）ですが、妙な情報が登録されている（同一タイトルのフィードが重複していたり）フィードを見かけたら、教えていただければ修正します。 _ 内部APIいろいろ 日本で公開されているAPI一覧（下書き）とかからリンクされてたんで、どうせなら1470.netリニューアル版内部で使っているAPIも一応書いておこう。内部用なんでいつまで使えるかは未保証だけど。 個人で使う分には外部から適当に呼び出して使ってもいいけど、ばりばり使う場合は、タグ系API以外はどうせ元ネタを公開（位置情報＋郵便番号データベース、鉄道路線＋駅位置情報データベー
ドメインウェブの設定が見つかりません 考えられる原因 ドメインウェブの設定がまだ行われていない。 ドメインウェブの設定がまだ反映されていない。(反映には数時間～24時間かかることがあります) ドメインウェブ・DNSの設定が誤っている。 アカウントが存在しない、契約が終了している、削除されている。
追記：清書としてusing API;でAPIに関するブログをはじめました。 「ProgrammableWeb: Web 2.0 Mashup Matrix」には海外のAPIがずらりと並んでいますが、日本語圏のAPIの最新のリストは見当たらなかったので集めてみました。 Nakamura-KU ADDICT <>invGeocoder のREST 緯度経度を引数に住所を返す写真共有「フォト蔵」Geocoding API – 住所から緯度経度を検索RSSナビ –開発者の方 (RSSナビ RSET API)Simple API – ウェブサイト・サムネイル化ツールlivedoor PICS WebService – livedoor PICS サービスのお知らせ – livedoor Wiki（ウィキ）ヨコナビ – livedoor ReaderのAPI一覧Weather Hacks – live
『入門 Ajax』（旧版） このページは、 『入門 Ajax』のサポートページのおまけの一部です。 『入門Ajax 増補改訂版』（新版）←お待たせしました。予約受付開始しました。 『入門Ajax 増補改訂版』のサポートページと バージョン2リファレンス(意訳とサンプル)は→こちら ＊2008.2.6 ようやくGoogle マップ API リファレンス 日本語版が公開されたようです!。(なお、このページの下記ミニサンプル約150本は、訳者が参考のために作成したもので、Googleのリファレンスには、各命令ごとのサンプルはありません。というわけで、このページ自体は残しておこうと思います。もし、今後とも多少の参考になれば幸いです。) 【Google Maps API 関連の更新情報】 2006.9.8 03-31 経度・緯度を調べる（地図作成作業補助サンプル）をアップデート v0.44 2006
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
