タグ

webapiに関するgologo13のブックマーク (8)

  • APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight

    ちょっと前にTwitterAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式(=コントローラ分割)でやってきて後悔したぼくが、(5年ぐらい前から)現在はどうやってAPIのバージョンを管理しているか?について紹介します。 基原理としては、コピペが多発する根っこで分岐(=コントローラ分割)じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー

    APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight
  • ホットペッパー | リクルートWEBサービス

    リクルートウェブサービス システムメンテナンスのお知らせ 以下の日程でシステムメンテナンス作業が予定されています。 システムメンテナンス期間中は、リクルートウェブサービスをご利用いただくことができません。 メンテナンス予定日時 2024年3月6日(水) 14時00分頃 ~ 20時00分頃 ※時間は前後する場合がございます。 ご利用中の方にはご迷惑をおかけしますが、何卒ご理解いただきますようお願い申し上げます。 【メンテナンス】下記の通り、システムメンテナンスのため、一部サービスがご利用頂けません。 サービスが提供する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を設計してみるとどんなインターフェイスがいいのか、どんな形式がいいのかといった疑問が次々と出てきます。

    WebAPIでエラーをどう表現すべき?15のサービスを調査してみた - Qiita
  • RESTのベストプラクティス | POSTD

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

    RESTのベストプラクティス | POSTD
    gologo13
    gologo13 2015/01/06
    だいたい同意だけど、英語苦手な人がいると単数系にした方がいい場合も。 アプリのためのAPIの場合、ステータスコード細かくしてもあまり使わなれないような。
  • #mozaicfm REST を聴いての感想 - ぶろぐ。@はてな

    mozaic.fmでRESTの回が企画されているということを、API Meetup #1 のときに yohei さんから直接聞いていたのですが、ついにそれが公開されたので、喜び勇んで聴きました。 mozaic.fm #7 REST 断片的に感想をツイートしたので、そのまとめです。 RESTの何が重要なのか さすがの t_wada さん。アーキテクチャとしてもそうだし、アプリケーションフレームワークも「適切な制約」を設けることで設計のコストが下がる、という話の流れでした。 “Constraints are liberating”「制約は自由をもたらす」は僕が好きな言葉ですが、これを知ったのはDHHのRubyKaigi 2006の講演からです。(初出はどこか別のところなのかも?) RESTの流行 原理主義者的発言をするなら、「REST API」と謳って世に出たWeb APIはただのJSON/X

    #mozaicfm REST を聴いての感想 - ぶろぐ。@はてな
    gologo13
    gologo13 2014/11/10
    mozaic.fm REST の会の要点まとめ。Richardson Maturity Model のレベルの話は知らなかった
  • ドメインパーキング

    mashupaward.jp

  • API比較・マッチングサービスAPI

    国内外のWebAPI約2,000のカタログ検索サービスです。APIの基スペックを表形式で表示。類似のAPIを素早く比較・対照し最適なもの を選定したり、APIの接続可能性や意味的つながりの相性を見ることができます。複数のカテゴリの組み合わせごとに、動的にフィードを生成することもでき ます。※API-matchとよんであげてください。 Webアプリ版の画面(Dual Details): http://www.api-match.com/ API呼出しURL http://www.api-match.com/search_api 入力パラメータ http://www.api-match.com/search_api?apikey=XXXXX&keyword=<URLエンコードした検索キーワード> apikey: apiキー keyword: UTF-8でURLエンコードした検索キーワード。(

  • 海外・国内の便利なAPI一覧 - API LIST 100+

    Android、iOS、Web環境での開発キットを提供。Google Play、Google+、Maps、YouTube、Books、Gmail、Cloud などのAPIも多数公開

  • 1