なぜポストREST APIが求められるのか？ REST APIがカバーできない2つの要因とその対策 - Morning Girl
なんだか珍しく、あおり気味のタイトルにしてしまいました。 最近読んだ以下の記事が大変おもしろかったので、今まで私の中で度々反芻していたものを文章としてまとめてみました。 gihyo.jp なぜ今GraphQLが騒がれているのか。ポストRESTが求められている理由、なぜポストRESTが求められなければいけないのか？ ポストRESTの登場によって私たちにとって何が嬉しくなるのか？ そのあたりを色々と触れていきたいと思います。 本文に入る前に ここでは、RESTと記載していものに、REST ful であることも含めています。RESTの推奨（規約ではない）に準拠して開発されたAPIをREST Fulと呼ぶのであって、そこにAPIとしての違いは無いためです。 どちらかと言えば、私の意識としてはパブリックなAPI、オープンデータ用のAPIであったり、KintoneやSANSAN、Salesforce、
API デザイン : URL には名前と識別子のどちらを使うべきか | Google Cloud 公式ブログ
ウェブ API の設計に携わっている方であれば、API で使う URL のスタイルに統一的な考え方がないことも、選択した URL スタイルが API の使いやすさや寿命に大きな影響を与えることも、よくご存じでしょう。Google Cloud の Apigee チームは、社内だけでなくお客様とも協力しながら、API の設計について長く検討を行ってきました。本稿では、私たちが設計の現場で実際に使用している URL のデザイン パターンと、それを使う理由についてシェアしたいと思います。 著名なウェブ API をご覧になれば、いくつかの異なる URL パターンがあることに気づかれるはずです。次に示すのは、極端に異なる考え方に基づいた 2 つのスタイルの具体例です。 https://ebank.com/accounts/a49a9762-3790-4b4f-adbf-4577a35b1df7 htt
『Web API: The Good Parts』読んだ - ✘╹◡╹✘
『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は後から変更するのが比較的難しいものなので、つらいものを使い続ける羽目になりやすい。また一貫性が重要視されやすいので
アクセストークンに有効期限を設けるべきかどうか - Qiita
OAuthプロバイダを提供することになったとして、アクセストークンに有効期限を設けるべきかどうかについて考えたい。OAuth 2.0の仕様にはアクセストークンの期限切れに関係する仕様が定義されているし、セキュリティをより強固にするためにアクセストークンは一定期間で期限切れにするべきだという主張があったと思う (確認していないので無いかもしれない)。しかしながら、例えばGitHub API v3ではアクセストークンに有効期限を設けていない。この投稿では、アクセストークンの有効期限に関係して起こり得る問題を取り上げる。 アクセストークンに有効期限を持たせておくとちょっと安全 アクセストークンが悪意のある第三者に漏洩してしまった場合、そのアクセストークンに認可されているあらゆる操作が実行可能になってしまうという問題がまず存在する。ここでもしアクセストークンに有効期限が存在していたとすれば、その操
Rubyist Magazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0062 号 バックナンバー Rubyist Magazine 0062 号 Kaigi on Rails 特集号 RubyKaigi Takeout 2020 特集号 Rubyist Magazine 0061 号 Rubyist Magazine 0060 号 RubyKaigi 2019 直前特集号 Rubyist Magazine 0059 号 Rubyist Magazine 0058 号 RubyKai
ブランドをAPI化する - ワザノバ | wazanova
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は同社のコンシューマ
You don't need API version 2 - yohei's diary
周回遅れ感が半端ないけどバージョニング関連で色々読んで・聞いて思ったことを書く。 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信者の主張であるものの、それが正しい（というか実用的）かど
rebuildfm 35のAPIの話が面白かった - wyukawa's diary
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回呼べば済むのでレイテンシの問題もなく
【追記あり2】Twitter のことと P3:PeraPeraPrv について - とかいろいろ
※一応Twitterに関してはライトユーザーよりは色々な情報を持っているつもりなのでw、どうしてこんなことをやるのか察しはついてます。が、いい加減一言言わないと気が済まないので書くことにしました。 最近何かと騒がしいTwitterの規約変更。 Twitter、開発者向けガイドラインとAPI変更について説明 ユーザー数制限など厳しい内容 - ITmedia ニュース via kwout Twitter Display Guidelines 日本語訳してみた 今これを全部クリアしているクライアントは少ないんじゃないでしょうか…？ どうやらV1.1適応後はこれを守らないとアプリケーションキーを剥奪されるみたいです。 これは本当に悪手だと言っておきます。サード切りとか言われてますが、要するにこれは 小さなスタートアップサービスが拡大する為にAPIを公開しても、成功したら裏切られる という悪しき前例
Twitter api ver1.1、痛いところ、痛くないところ
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の内容によって変わります。今までは
クローンサービスのAPIデザイン - bits and bytes
最近トラブル続きのTwitterのかわりにWassrを使いはじめたひとたちにフォローしていただいてたくさんメールが来ました。 去年たくさんできたtwitterみたいなサービスの中で、自分が注目していたのはもごもごとWassrです。このふたつのサービスにはTwitter同様APIが用意されているだけでなく、そのAPIがTwitterのAPIと互換になっていると書かれていたからです。 1年前に書けばよかったのにとおもいつつ、今日はサービスのAPIがほかのサービスと互換にすることについて書きます。 いいところ 既存のサービスと完全に同じAPIにすると、そのサービス用に作られたツールを少し改造すればそのまま新しいクローンのサービスで使うことができるようになります。 Twitterのクローンであれば、そのサービスにTwitterとおなじAPIを用意すれば、Twitter用に作られた多数のツールをその
tomblooハックス - WordPressにポストするためのMetaWeblog API � ku
アップデート 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ページを開く
HTTP API の設計方向
Hypermedia: The Missing Element to Building Adaptable Web APIs in Rails
usingapi.com is available for purchase - Sedo.com
Amazonの商品データベース提供打ち切りで物々交換サイトに影響