これからの MicroservicesDeNA TechCon 2016 の発表資料です。 REST と JSON の突っ込んだ話と、ちょっと Microservices の話。タイトルに偽りありです。
API Documentation & Design Tools for Teams | Swagger
NEWAPI Documentation Portal API Development for Everyone Simplify API development for users, teams, and enterprises with the Swagger open source and professional toolset. Find out how Swagger can help you design and document your APIs at scale. Explore Swagger Tools SmartBear Named a Visionary by Gartner® in the 2023 Magic Quadrant™ for API Management Learn More
RESTとJSON、スキーマ定義について思うところ
mozaic.fm #7 RESTや#mozaicfm REST を聴いての感想、それから「Web+DB vol82のWebAPIデザインの鉄則」に触発されたので書こうと思う。 REST設計について WebAPIを設計するうえでRESTが重要であることは周知のとおりである。 “Constraints are liberating”「制約は自由をもたらす」 @t_wadaさんがおっしゃっているように、RESTを前提にすれば、「アーキテクチャとしてもそうだし、アプリケーションフレームワークも「適切な制約」を設けることで設計のコストが下がる」という大きなメリットが生まれる。 しかし、相変わらずリソース設計やらインターフェース設計やらで悩んでおられる方も多いと聞く。 その一方で個人的には適切なフレームワークを使えばREST設計で悩まなくてもよいはず(※3)という思いもある。 インターフェース設計な
RESTのベストプラクティス | POSTD
現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR
RESTful Web API 開発をささえる Garage (client 編) - クックパッド開発者ブログ
料理動画事業室の @yoshiori です。前に「RESTful Web API 開発をささえる Garage」で紹介した RESTful Web API を開発する Garage のクライアント側のライブラリを公開しました。この記事ではその使い方を紹介したいと思います。Garage の設計思想やサーバ側の実装については上記記事を御覧ください。 今回は簡単にクライアント側の挙動を知っていただくために pry を使って説明したいと思います。 アクセスするサーバは先程の記事で作成したアプリケーションを使用してみます。 サーバの準備 https://github.com/taiki45/garage-example の README にも書いてありますので簡単に進めたいと思います。 まずは下準備としてコードを github から clone してきて、ライブラリのインストールと DB のマイグレ
Railsの誤解：CRUDはRESTじゃない！ - 杉風呂2.0 - A Lifelog -
以下はNick Sutterer氏が2010年10月28日に自身のブログに投稿した、"Rails Misapprehensions: CRUD is not REST! "の翻訳です。本人の許可を得て掲載します。 Rails Misapprehensions: CRUD is not REST! http://nicksda.apotomo.de/2010/10/rails-misapprehensions-crud-is-not-rest/ RailsとRESTについて調べている間、二つのことがよくわかった。 RailsでRESTがどうなっているのか、他と比べて、明解で、基礎的で、「印刷された」解説を見つけにくい。数千のスクリーンキャストを見てきたが、この素晴らしいガイドが一つあるだけだった。 みんなCRUDとRESTを混同している とりわけ後者は僕を困らせたが、あるチームをコーチすると
RESTfulなAPIのドキュメントを管理·ApiDocco MOONGIFT
ApiDoccoはRESTfulなWeb APIのドキュメントを作成できるWebサービスです。 Web APIを使ってWebサービスを作る、またはWebサービスを作ったらWeb APIを提供するというのは当たり前になってきました。その際に必要になるのがドキュメントです。一から作るのは大変ですが、ApiDoccoを使えばある程度手軽に作れるようになりそうです。 トップページです。APIは独自で追加もできます。 APIDoccoのAPIを見ています。RESTfulなメソッドが並んでいます。 GETアクセスの一覧系です。必須パラメータやそのレスポンスが確認できます。 POSTアクセスでも同じように表示されています。 切り替えはスムーズで内容も見やすいです。 ApiDoccoは左側にメソッドの一覧、右側に実行の際のパラメータとレスポンスを記します。その場で実行が出来る訳ではないようですが（将来的に
RESTに対する７つの誤解
海外に行くと、既に REST対SOAPの決着は付いている[1]（エンタープライズでもコンシューマでも）ように見えるのだが、日本国内で話していると、まだまだ混乱しているようだ。さながら2009年ごろの状況を見るようだ。そこで、今日は RESTに関わる誤解について、幾つか書いてみたいと思う。（殴り書きだが、あんまり聞かれるのでFAQとして。なお、以下の多くは、[2] サービスステーション：RESTの詳細でより詳細に書かれている。） 誤解1. RESTはマッシュアップ用のプロトコルで、サーバ間通信には適さないのではないか？ どこからこのような誤解が来ているのか理解に苦しむ。ひょっとすると、RESTはHTTPベースということが、ブラウザとWebサーバのやり取りという風に誤って捉えられているのかもしれない。 もちろん間違いである。 ブラウザとWebサーバとの間同様、サーバからサーバへの通信にもHTT
URLに関する議論 -- なぜ僕はクエリパラメータを擁護、ときに推奨するのか - 檜山正幸のキマイラ飼育記 (はてなBlog)
一時期（2010年の1月頃）、URLの議論をしていて、僕は拡張子を含むURLやクエリパラメータを擁護していました。 そろそろ決着、HTTPメソッド、URL、そして標準化された動詞 RESTfulなWebサイトと拡張子を含むURLについて 最近、またURLの問題を考えてみたのですが、僕が拘っているのは次の2点なのだと気付きました。 すべてのURLを列挙したい。 すべてのURLを分類したい。 すべてのURLを列挙したい あるWebサイトやWebアプリケーション（以下、総称してWebシステム）を考えたとき、有効なURLを完全に列挙したいのです。ここでの「URL」は、正確に言えばクエリパラメータを含まないパス部分のことです。もちろん、有効なURLは時々刻々と変化します。でも、ある一時点を取れば、その時点におけるURLは確定するはずです。各時点ごとのURLの集合を100%把握したいのです。 列挙する
RESTfulなWebサイトと拡張子を含むURLについて - 檜山正幸のキマイラ飼育記 (はてなBlog)
2009年12月16日「チュートリアルを少し変更、おバカな設定例」 Catyでは、ファイル名拡張子の意味付けや扱い方がデスクトップと同じなんだけど、「クールなURIは、拡張子がねーんだぞ」とか言われそうだから、そのうちラショネールを書かなきゃ。 「ラショネール」なんて奇妙な言葉が出てきてますが、目論見や主張が正当であることを示す根拠、てな意味ですかね＞ラショネール。 僕とKuwataさんが開発しているWebフレームワークCatyは、URLに、.html, .cgi などの拡張子を必ず要求します。クエリパラメータも遠慮なしに使います。「拡張子とかクエリパラメータなんて、RESTfulじゃないなー、クールじゃないなー」とか言う人がいますが、なにゆえに「拡張子やクエリパラメータがダメなのか？」 -- その根拠を示して欲しいもんです。僕らが積極的に拡張子やクエリパラメータを使う事情と根拠は、このエ
そろそろ決着、HTTPメソッド、URL、そして標準化された動詞 - 檜山正幸のキマイラ飼育記 (はてなBlog)
（[追記 date="翌日"]文言を少し改善し、注意を付け足したりしました。[/追記]） HTTPメソッド、URL、動詞（verb）に関して次の記事を書きました。 HTTPメソッドの正統的使い方と現実的対処法 HTTPメソッド、URL、そして標準化された動詞 訂正補足：HTTPメソッド、URL、そして標準化された動詞 問題点がほぼ明らかになり、全体の状況も見えてきたので、総括したいと思います。これで決定版にしたいのですが、実のところ、まだ考えが変わる可能性は否定できません。現時点では、以下に記述する案が最善だと思っていますがね。 内容： 用語の注意 事の発端，事の成り行き URLの意味と用途を分類する リソース種別ごとに動詞を考える さらにリソース種別ごとに動詞を考える GETに乗せるか、POSTに乗せるか インターフェースとしてのリソース種別と動詞 リソースとクラス 用語の注意 HTTP
Documentation Home
<g> <g> <defs> <rect id="SVGID_1_" x="-468" y="-1360" width="1440" height="3027" /> </defs> <clippath id="SVGID_2_"> <use xlink:href="#SVGID_1_" style="overflow:visible;" /> </clippath> </g> </g> <rect x="-468" y="-1360" class="st0" width="1440" height="3027" style="fill:rgb(0,0,0,0);stroke-width:3;stroke:rgb(0,0,0)" /> <path d="M13.4,12l5.8-5.8c0.4-0.4,0.4-1,0-1.4c-0.4-0.4-1-0.4-1.4,0L12,10.6L6.2
yohei-y:weblog: REST 入門
日本語の REST のリソース集を以前作ったのだが、 日本語では一般人向けの解説がない。 sheepman 氏の REST のページはすばらしいんだけど、多少わかっている人向けだ。 市山氏のプレゼン資料は RoyF の論文を詳しく解説していてよいのだけれど、いかんせんアカデミックすぎる。 技術的な要素も抑えつつ、入門者にもわかりやすい解説はないものかと探していたのだが、みつからない。 英語の文書を訳すことも考えたんだけど、あまりよいものが見つからない。 で、結局自分で書くことにした。 最初はひとつのポストで済ませるつもりだったんだけど、書き始めたら長くなってしまったので、複数のポストに分けることにした。 えらそうなことを書いたが、内容は「ないよりマシ」といったレベルだろう。 前書きが長くなったけど(ここから始まりです。ですます調なのは入門記事だから)、 この記事(から始まる一連のポスト)は
Representational State Transfer - Wikipedia
この記事には独自研究が含まれているおそれがあります。問題箇所を検証し出典を追加して、記事の改善にご協力ください。議論はノートを参照してください。（2023年11月） Representational State Transfer (REST、レスト[1][2][3][4]) は、ウェブAPI（ウェブアプリケーションプログラミングインタフェース）の定義に使用されるアーキテクチャスタイル（共通仕様）[5]であり、同時にウェブのような分散ハイパーメディアシステムのためのソフトウェアアーキテクチャのスタイルのひとつでもある。この語はHTTPプロトコル規格の主要著者の一人であるロイ・フィールディング（英語版）がウェブについて書いた2000年の博士論文で初めて現れ、ネットワーキングコミュニティの中ですぐに広く使われることになった。 RESTは、初めはアーキテクチャの原則と制約の集まり（後述）を指してい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Welcome