http api design
以下なドキュメントを発見しておりまして。 HTTP API Design Guide なんとなくメモをとってみました。 Contents として以下が列挙されています。 適切なステイタスコードを戻しなさい 戻すことができる全てのリソースを戻しなさい リクエストボディに含まれるシリアライズされた JSON を受け付けなさい ID じゃなくて UUID 使った方が良いですよ 標準的なタイムスタンプを使いましょう UTC 時刻は ISO8601 フォーマットで使いましょう 一貫性のあるパスフォーマットを使いましょう 小文字とダッシュを使いましょう 外部キーのリレーションは入れ子に 利便性をはかるため non-id dereferencing をサポートしなさい エラーの場合のレスポンスボディについて ETag ヘッダを含めなさい Request-Id ヘッダを API レスポンスに含めなさい P
Ruby geocoderがすごい - もぎゃろぐ
住所を緯度経度に直したり、緯度経度から住所を求めたりする操作をgeocodingと言って、Google Maps APIを使うとまあたいていのことはできる。 ロケタッチAPIとか、Yahoo!ジオコーダAPIという手もある。 それはともかく、そのへんをパチパチ叩くコードを書いていて、「こんなのもうとっくに誰かが書いてんじゃないかなー」と思ってぐぐってみたらなんかすごいのが出てきた。 Ruby Geocoder 住所と緯度経度の相互変換はもちろん、距離や範囲の扱い、Google以外のAPIへの対応、キャッシュ処理など、「実装しようかなー。でもめんどくさいよね」とか思って先送りしていたような機能がほとんど全部実装されている。 住所の取得 require 'geocoder' # 日本語ロケールに設定 Geocoder.configure( :language => :ja, :units =>
「その目的にはこのAPIを使うのが最適です」、最適なAPIをワトソンの技術で教えてくれる、米IBMが「API Harmony」発表
「その目的にはこのAPIを使うのが最適です」、最適なAPIをワトソンの技術で教えてくれる、米IBMが「API Harmony」発表 クラウドの普及と歩調を合わせるように、利用可能なAPIが飛躍的に増加しています。例えば、サーバインスタンスやネットワーク、ストレージといったアプリケーションの実行に必要なリソースの構成から、ユーザー情報、地図情報、センサーの情報の取得、アプリケーションによる分析機能や集計機能の呼び出しなど、すべてAPI経由で呼び出すことが可能になってきています。 同時に、多数のAPIを用いた疎結合によるシステム構築も一般的になってきました。 一方で、利用可能なAPIが増加して似たような機能のAPIが林立するようになり、しかもAPIごとにバージョンやオプションが多数存在するとなると、ある目的に対してどのAPIをどう利用するのがもっとも適切なのかという判断は、どんどん難しくなって
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
