Twitter の TL に Dropbox が API v2 で REST をやめたという内容がかかれている記事が流れてきた。
SOAP、WSDL、UDDIなどを基盤とするWebサービスの標準化を行ってきた団体WS-I(Web Services Interoperability Organization)が、2002年からの約8年間の活動に幕を下ろしたことを正式に発表しました(参考:WS-I Completes Web Services Interoperability Standards Work(pdf))。 WS-Iは、WS-*と総称されるWebサービスのさまざまなプロトコル策定に取り組んできましたが、複雑すぎるといった評判がつきまとい、また策定そのものにも予想以上の時間がかかったことなどで、当初の想定ほど普及に至りませんでした。 そのSOAPに代わり、ここ数年サービス間をつなぐAPIとして存在感が高まっているのがREST(Representational State Transfer)と呼ばれるアーキテクチ
現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR
Web API(WebサービスAPI)をプログラミングで活用するにあたって,ぜひ知っておきたい基礎技術が三つあります。古典的な技術の代表としてSOAPとWSDL,そして昨今急速に普及してきたRESTです。ごく単純に言ってしまうと,前者は「高機能で複雑」,後者は「シンプルで簡単に利用可能」と区別できるでしょう。現時点では,そのシンプルさが多くの開発者に受け入れられたおかげか,REST方式が(先達である)SOAP方式を圧倒しているように見えます*1。 もっとも,だからといってRESTがSOAPよりも優れていると結論付けるのは早計でしょう。昨今では,SOA(Service Oriented Architecture)という言葉に代表されるように,大規模なシステムを「サービス」という単位で構成し,互いに連携し合う設計手法が注目されています。特に,SOAを実現する具体的な基盤技術として注目されている
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く