なんだか珍しく、あおり気味のタイトルにしてしまいました。 最近読んだ以下の記事が大変おもしろかったので、今まで私の中で度々反芻していたものを文章としてまとめてみました。 gihyo.jp なぜ今GraphQLが騒がれているのか。ポストRESTが求められている理由、なぜポストRESTが求められなければいけないのか？ ポストRESTの登場によって私たちにとって何が嬉しくなるのか？ そのあたりを色々と触れていきたいと思います。 本文に入る前に ここでは、RESTと記載していものに、REST ful であることも含めています。RESTの推奨（規約ではない）に準拠して開発されたAPIをREST Fulと呼ぶのであって、そこにAPIとしての違いは無いためです。 どちらかと言えば、私の意識としてはパブリックなAPI、オープンデータ用のAPIであったり、KintoneやSANSAN、Salesforce、
ウェブ API の設計に携わっている方であれば、API で使う URL のスタイルに統一的な考え方がないことも、選択した URL スタイルが API の使いやすさや寿命に大きな影響を与えることも、よくご存じでしょう。Google Cloud の Apigee チームは、社内だけでなくお客様とも協力しながら、API の設計について長く検討を行ってきました。本稿では、私たちが設計の現場で実際に使用している URL のデザイン パターンと、それを使う理由についてシェアしたいと思います。 著名なウェブ API をご覧になれば、いくつかの異なる URL パターンがあることに気づかれるはずです。次に示すのは、極端に異なる考え方に基づいた 2 つのスタイルの具体例です。 https://ebank.com/accounts/a49a9762-3790-4b4f-adbf-4577a35b1df7 htt
見てみると、たしかに Get 系の API だとしても POST を利用しているし、API の URL 設計に get_shared_link_file のようによく言われる REST っぽい設計は使っていなかった。 この方針は同意だ。自分は結構前に REST っぽい API を捨てることにした。だからといって REST API がダメだとかは思っていない。 一般ユーザが使う場合の API は REST API であるほうが慣れ親しんでいる場合が多いからだ。 AWS で利用されている HTTP API 仕様AWS の DynamoDB の Erlang/OTP ドライバーを書いているときに気づいたのだが、AWS の一部のサービスはかなり独特な API の仕様になっている。
『Web API: The Good Parts』を読んだ。贈ってくれた人達ありがとうございます。 Web API: The Good Parts 作者: 水野貴明出版社/メーカー: オライリージャパン発売日: 2014/11/21メディア: 大型本この商品を含むブログ (2件) を見る 目次 詳細はO'Reillyのページにて。 1章 Web APIとは何か 2章 エンドポイントの設計とリクエストの形式 3章 レスポンスデータの設計 4章 HTTPの仕様を最大限利用する 5章 設計変更をしやすいWeb APIを作る 6章 堅牢なWeb APIを作る 所感 Web API、よく知らない場合はとりあえず作りやすい方法で作っていこうという気持ちになりやすい。しかし、Web APIは後から変更するのが比較的難しいものなので、つらいものを使い続ける羽目になりやすい。また一貫性が重要視されやすいので
OAuthプロバイダを提供することになったとして、アクセストークンに有効期限を設けるべきかどうかについて考えたい。OAuth 2.0の仕様にはアクセストークンの期限切れに関係する仕様が定義されているし、セキュリティをより強固にするためにアクセストークンは一定期間で期限切れにするべきだという主張があったと思う (確認していないので無いかもしれない)。しかしながら、例えばGitHub API v3ではアクセストークンに有効期限を設けていない。この投稿では、アクセストークンの有効期限に関係して起こり得る問題を取り上げる。 アクセストークンに有効期限を持たせておくとちょっと安全 アクセストークンが悪意のある第三者に漏洩してしまった場合、そのアクセストークンに認可されているあらゆる操作が実行可能になってしまうという問題がまず存在する。ここでもしアクセストークンに有効期限が存在していたとすれば、その操
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0064 号 バックナンバー Rubyist Magazine 0064 号 Rubyist Magazine 0063 号 Rubyist Magazine 0062 号 Kaigi on Rails 特集号 RubyKaigi Takeout 2020 特集号 Rubyist Magazine 0061 号 Rubyist Magazine 0060 号 RubyKaigi 2019 直前特集号 Rubyist
This document summarizes Takuto Wada's presentation on reviewing RESTful web apps. It discusses best practices for designing RESTful resources and representations, including using nouns instead of verbs in URLs, making URLs reflect the meaning of resources, and ensuring resources are connected through hypermedia links and forms. It also covers appropriate use of HTTP methods, status codes, and con
An important trend is the API-ification of everything. As more and more business are accessible with a web API, the Internet becomes more and more powerful. - "New RFS -- Breakthrough Technologies by Sam Altman" (重要なトレンドは全てがAPI化していくこと。もっともっとビジネスがweb APIでアクセス可能になれば、ネットはもっともっとパワフルになる。) ウォッカで有名なAbsolutは、現在はフランスのPernod Ricardが親会社になってますが、元来はスウェーデンのブランド。欧米ではクールな広告宣伝をする会社として知られています。Eva Sjökvistは同社のコンシューマ
周回遅れ感が半端ないけどバージョニング関連で色々読んで・聞いて思ったことを書く。 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信者の主張であるものの、それが正しい（というか実用的）かど
Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima)の最後の方のAPIの話が面白かったのでそれについて書いてみる。 HTTP JSON APIにしろHiveServerが提供しているようなThrift APIにしろバックエンドにあるAPIサーバーにクライアントがアクセスして情報を取得してそれをもとに画面表示するっていうパターンは多いと思います。ここでいうクライアントってのは別にPCブラウザに限らなくてiPhoneやAndroidのようなスマートフォンだったりタブレットだったりいろんなケースがありえます。 iPhoneアプリでトップページを表示するのにAPIを10回叩く必要があるとかだと、レイテンシの問題もあるし開発の手間も増えますよね。そうじゃなくてiPhone専用のAPIみたいなのがあればそれ1回呼べば済むのでレイテンシの問題もなく
※一応Twitterに関してはライトユーザーよりは色々な情報を持っているつもりなのでw、どうしてこんなことをやるのか察しはついてます。が、いい加減一言言わないと気が済まないので書くことにしました。 最近何かと騒がしいTwitterの規約変更。 Twitter、開発者向けガイドラインとAPI変更について説明 ユーザー数制限など厳しい内容 - ITmedia ニュース via kwout Twitter Display Guidelines 日本語訳してみた 今これを全部クリアしているクライアントは少ないんじゃないでしょうか…？ どうやらV1.1適応後はこれを守らないとアプリケーションキーを剥奪されるみたいです。 これは本当に悪手だと言っておきます。サード切りとか言われてますが、要するにこれは 小さなスタートアップサービスが拡大する為にAPIを公開しても、成功したら裏切られる という悪しき前例
Twitter apiのガイドラインが改定になるそうです。 Twitter API v1.1でのAPI利用ルールの変更について こちらの日本語ブログは当たり障りのないところしか書いてないので、関係者は英語の方を読むことを強くおすすめします。 Changes coming in Version 1.1 of the Twitter API どうしてもこういう制約が増えるものは、ネガティブが極大化するので、ちょっと冷静に見てきましょう。 ■すべてのapiのエンドポイントに認証が必要、さらにレートリミットの変更 現在、検索apiなどはOAuthの認証が不要で、IPアドレス毎に一時間あたりのアクセス数が定められていますが、これが廃止になり、2013年3月までに全てOAuth認証を通した方法に変更を求めています。 さらに、１時間毎にapiにアクセス可能な数が、apiの内容によって変わります。今までは
最近トラブル続きのTwitterのかわりにWassrを使いはじめたひとたちにフォローしていただいてたくさんメールが来ました。 去年たくさんできたtwitterみたいなサービスの中で、自分が注目していたのはもごもごとWassrです。このふたつのサービスにはTwitter同様APIが用意されているだけでなく、そのAPIがTwitterのAPIと互換になっていると書かれていたからです。 1年前に書けばよかったのにとおもいつつ、今日はサービスのAPIがほかのサービスと互換にすることについて書きます。 いいところ 既存のサービスと完全に同じAPIにすると、そのサービス用に作られたツールを少し改造すればそのまま新しいクローンのサービスで使うことができるようになります。 Twitterのクローンであれば、そのサービスにTwitterとおなじAPIを用意すれば、Twitter用に作られた多数のツールをその
アップデート 2008.6.24 mattnさんにいただいたBig Sky :: tomblooハックス90_MetaWeblog.jsのパスワードをパスワードマネージャに保存するパッチを文字化けしないようにしてtombloo - Google Codeにコミットしました。ページのView raw fileのところからダウンロードしてください。 tomblooはtumblr専用のツールではありません。tomblooのポストする先をWordPressに変えればtomblooからWordPressにポストすることができて、自分専用プライベートtumblelogとか、社内でチーム共有のtubmlelogを作ってtomblooからポストすることもできます。MetaWeblog API posterはそのためのパッチです。 ダウンロード 90_MetaWeblog.js (for Firefox3)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
