このガイドラインは、主にAzureチームによってクラウドサービスの構築作業で開発、使用されている。ここで、我々はドキュメントの完全な説明については興味がある読者に任せ、MicrosoftのAPIガイドラインからいくつかの主なポイントを要約する。クライアントライブラリを必要とすることなしに、APIの採用を促進するために、URLは人にとって可読性が高く構築可能であるべきである。HTTP動詞としてGET、PUT、DELETE、POST、HEAD、PATCH、OPTIONSがサポートされる。全てのリソースが全ての動詞をサポートすべきというわけではない。カスタムヘッダが必須であってはいけない。ログファイルを通して公開される可能性があるので、クライアントは、URL内でPIIを転送すべきではない。パラメータはヘッダを通して渡されるべきである。データは、人気の高いフォーマットで提供されるべきである。デフォルトのデータエンコーディングは、JSONである。4627の規則に従って、JSONでシリアライズされなくてはならない。APIを使う開発者は、好みの言語とプラットフォームを使えるべきである。サービスは、curlのような単純なHTTPツールからでさえもアクセス可能であるべきである。APIは、明示的なバージョニングをサポートすべきである。サービスは、可能であれば、破壊的変更を導入することなく安定的であるべきである。必要な場合には、破壊的変更の導入が許されるべきであり、破壊的変更を示すためにバージョン番号を増やす。バージョニングは、「メジャー.マイナー」スキームを使って行われるべきである。介して、プッシュ通知を実装しても構わない。このガイドラインは、適切に構造化されたURLだと考えられているものの例を提供している。https://api.contoso.com/v1.0/people/jdoe@contoso.com/inboxそして、これが避けるべきURLの例である。Fielding氏が、このガイドラインに対する次のような不満を表明した。示されている内容よりずっと優れています」。InfoQは、Fielding氏がこのガイドラインに満足していない理由の詳細を知るために、彼に連絡した。彼の返信をすべて公開する。私は、Microsoftのような企業が、内部のドキュメントや開発ガイドラインをパブリックなフォーラム、特にGitHubのようなオープンな協力の場に公開する決断をしたことは、素晴らしいと考えています。パブリックな会話に対するオープンさは、我々全てが業界内で作業する方法を大幅に改善するでしょう。APIだとされている点です。RESTに関する関連資料をざっと読めば明らかなように、RESTはHTTPではありません。私の仕事を参照しようとすらしていません。これは、SOAP/RPCインタフェースのある種のHTTPバージョンとしてRESTを説明するという、以前に深くWebサービスの世界にいた人々によくある間違いです。実際にこの間違いがどんなによくあるものだとしても、RESTのふりをすることはできません。RESTアーキテクチャスタイルの性質のほとんどは、過去の失敗したツールに都合よく似ている制約だけではなく、RESTアーキテクチャスタイルの制約の全てを守ることから来ています。APIと呼ぶならば、私はその人々に異存はありません。それはRESTではありません。それはWebからのものではありません。これは、HTTPを使ったRPCをHTTPサービスとして説明、実装できない、という意味ではありません。従う必要性を感じることなく、その実装ガイドラインを議論することに、価値があります。APIを作成し、それを使うことに非常に成功している。クラウドコンピューティングのほとんどは、こういったAPIを基にしている。多くのプロバイダが、APIが「RESTful」ではないのに「RESTful」だと主張しているのかは、依然として謎である。