この記事はPepabo Advent Calendar 2014の11日目の記事です。 前日は、tnmtさんのVagrantのshell provisionerでApacheのビルド済tarボールをOSバージョン毎に作る術でした。 はじめに 今回は、Web APIを作るときに考えることをまとめました。 本当は、社内向けに資料を作っていて、社内の勉強会とかで話せればいいか〜って考えていたんですが、アドベントカレンダーのネタが本当になくて困っていたのでこれを使います。 対象者 APIを作る時、と書いてますが、クライアント側の人にとっても知っておく必要があることなので、サーバ側の人・クライアント側の人両方が対象者です。 APIを作るときに考えること 「APIを作るとき」と言っても、色んな状況があります。 まずはそれを絞ります。 APIの種類 プライベートAPI アプリのAPIなど使う人が限定され
Normally, not all resources and collections implement all methods. There are two ways to find out which methods are accepted by a resource or collection. Use the OPTIONS method on the URL, and look at the “Allow” header that is returned. This header contains a comma-separated list of methods are are supported for the resource or collection. Just issue the method you want to issue, but be prepared
お問い合わせの前に… よくあるご質問(ヘルプ)はこちら アフィリエイト以外のご質問はこちら サポート窓口 平日11：00～18：00 ※お問い合わせ内容や状況により確認および対応にお時間を要する場合がございます
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sightにはブコメしたのですが、Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima)でも本件に言及があったようなので、少し一般論を書いておきたいと思います。 ■Web APIの設計原則について そもそも、良いAPIとはどのような特性をもつものでしょうか？ 一般的に、以下の２点が挙げられると思います。 拡張が容易である 拡張時に後方互換性を破壊しない ウェブの場合は、これに加え、 スケーラブルである HTTPに起因する問題に上手に対処できる ことが求められます。 前２者はウェブに限らない要件です。これを満たす設計手法としては、 リクエストおよびレスポンスのパラメータを拡張可能に 互換性を壊す拡張が必要な場合は、関数名を変える 古い関数は従来と同じ機能を
周回遅れ感が半端ないけどバージョニング関連で色々読んで・聞いて思ったことを書く。 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信者の主張であるものの、それが正しい（というか実用的）かど
4/12(土)の夜に『RESTful Meetup vol.3』を開催しました。 RESTful Meetup vol.3 - Sendagaya.rb | Doorkeeper 昨年の記事の通り『RESTful Web APIs』の読書会を月2回ペースで開催してきましたが、その後、著者のMike Amundsen(@mamund)さんから、ワークショップのために東京へ行くという知らせがあったので、これはイベントをやるしかない！ということで企画しました。 vol.3ということで、実は過去2回開催しています。そのときは『RailsにおけるRESTfulなURL設計勉強会』というタイトルで、かなりターゲットを絞っていたのですが、今回は「REST」「Web API」というかなり広いテーマにしました。このことでRuby/Railsに限らず多様な言語の人に集まってもらえたのがとてもよかったです。 ビ
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
Accurately conveying Japan, present and future, to the world. Mission Providing trustworthy information that deepens understanding of, and generates interest in, Japan. 世界中で、日本に興味を持つ人を増やし、日本についての理解を深めるために、私たちは、信頼できる情報を提供します。 Vision Contributing to a better world through the promotion of mutual understanding between Japan and various international communities. 日本と世界の相互理解を推進することで、よりよい世界の実現に貢献します。
ウィキペディアでは日付ごとに「今日は何の日」情報の記事ページが作成されています。 ex. "10月24日"のページ このウィキペディアのページを解析して、「今日は何の日」情報をXML形式で返すAPIです。 ex. "10月24日"のXML 解析結果のXMLは本サイトのサーバ内にキャッシュされているので、APIの動作は軽快です。 いろいろとマッシュアップできそうです。何か面白いもの作った方は教えてください。 以下のURLにリクエストするだけです。 http://www.mizunotomoaki.com/wikipedia_daytopic/api.cgi/[日付] [日付]の部分に、情報を取得したい日付を指定します。（MMDD, M-D, M/DいずれでもOK） 存在しない日付を入れるとtext/htmlなエラーメッセージが返ったりしますが、エラーチェックはあまり厳しくな
2013年のいま、API界隈が熱い！ 今年に入り、官公庁の統計データやNHKの番組情報など、今までなかなか利用できなかったデータがAPIとして扱えるようになってきました。このエントリでは現在公開されているAPIを一覧でまとめます。いま使えるAPIはこれだけ読めば大丈夫。2013年の最新マッシュアップ事情をあますとこなく網羅します！ HOT! API 総務省 次世代統計利用システム（国勢調査、人口推計、就業構造、企業統計、物価統計 etc.） NHK番組表（※未公開） 行政・自治体・公共サービス 郵便番号 郵便番号検索API（郵便番号 → 住所） 郵便専門ネット（郵便番号 → 住所、郵便番号の簡易存在チェック） ぽすたん（郵便番号 → 住所、住所 → 郵便番号） IW3 PROJECT（郵便番号 → 住所、住所 → 郵便番号） 宇宙 Google+ JAXA PR（※現在一部の学生に限定公開
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
Google CGI API for Japanese Input Google CGI API for Japanese Input は、日本語変換をインターネット上で実現するための、CGI サービスです。 リクエスト http://www.google.com/transliterate に対して HTTP リクエストを発行します。GET メソッドを使ってください。以下の CGI パラメータを（URL エンコードした上で）指定します。 langpair=ja-Hira|ja text=（変換したいひらがな列） text のひらがな列は UTF-8 でエンコードします。例えば、「へんかん」をリクエストする場合は、 http://www.google.com/transliterate?langpair=ja-Hira|ja&text=%E3%81%B8%E3%82%93%E3%81%8B
LocoSticker位置情報付きコンテンツ検索API 緯度経度を入力すると、その周辺について書かれたブログのURLをJSON形式で 応答します。 LocoSticker位置情報付きコンテンツ検索の体験
パイオニアは11月7日、音声制御によるクラウドベースの統合Webサービスプラットフォーム「Zypr」の提供を開始したと発表した。iOS、Android、HTML5、Javaの開発者は無償でZyprのAPIを利用できる。 開発者はZyprを利用することで、アプリにFacebookやTwitterを音声で制御する機能を追加できる。現在Zyprがサポートするのは、上記2サービスの他、Google、Amazon.com、Yelp、天気予報サービスのAccuWeather、リアルタイム交通情報のINRIX、ネットラジオのSlacker Radioなど。モバイル端末、テレビやオーディオなどの家電、車などに搭載することで、米Appleの「Siri」のように音声で端末に指示を出すことができるようになる。 開発者はZyprに加入し、開発したアプリはパイオニアの審査を受けてからwww.zypr.netに登
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
