一部のテクノロジーが「標準」であるとはどういう意味ですか？
プログラミングにおける「標準」という用語は、多くの場合、グループまたはコミュニティによって管理されるテクノロジー/ドキュメントを指します。そのグループのメンバーは、多くの場合、共通の投資目標を共有し、そのテクノロジーのアクティブユーザーであり、テクノロジーの継続を保証したいと考えています。
プログラミングには、それらを管理するコミュニティーを持つ「もの」がたくさんあります。これらのメンバーは、プログラマーから企業の代表者（Apple、Microsoft、IBMなど）までさまざまです。
W3Cは非常に大規模なグループで、連携して多くの標準を定義しています。
メンバー一覧はこちら。
http://www.w3.org/Consortium/Member/List
RESTはテクノロジーの例であり、その人気により多くの人が使用していますが、RESTを管理するグループやコミュニティーはありません。したがって、指を向けて発言する場所は1つもありません"それは標準がそれを行うべきであると言う方法です]。
IBM、Microsoft、その他の企業は、RESTの実装方法に関するドキュメントを公開しています。 RESTを実装する「一般的な方法」があると言えるでしょう。 RESTの実装を説明する信頼できるソースを選択し、そのリファレンスに従うと主張できます。 信頼できるソースの使用は、Webブラウザーの互換性の問題に対処してきた1つの方法です。
標準は、テクノロジーの動作を指定する技術文書です。 （一部のテクノロジーでは、それは他の種類の 技術標準 である場合があります。）それがすべてであり、それらが存在する理由です。それらはドキュメントであり、テクノロジーを説明しています。
これらのドキュメントは、テクノロジがどのように機能するかを決定できるように、また仕様ドキュメントを標準としてリリースするときに注意を払うために必要な権限と信頼を持つ管理機関によって作成されています。統治機関は、さまざまなテクノロジまたはテクノロジのさまざまなバージョンについて、多くの標準を作成できます。統治機関は、標準の管理者、作者、管理者などとしても知られています。
（マシューの説明とは対照的に、標準はではありません統治体norテクノロジー自体。それは、ドキュメントテクノロジー（またはその特定のバージョン）を説明するです。）
あなたが言及した（そして他の）テクノロジーのいくつかの標準例：
- [〜＃〜] soap [〜＃〜] 標準で、W3Cによって維持されています。
- STD66 で定義されたURI標準は、インターネットエンジニアリングタスクフォース（IETF）によって保守されており、IETFも作業しています...
- HTTP 1.1仕様 、 HTTPワーキンググループ によって作成されました。これらはコメント要求（RFC）ですが、それでもHTTPの動作を指定します。これらの標準は実際には非常に新しい、2014年6月にリリースされただけです。HTTP1.1は以前 RFC 2616 で定義されていました。 IETFネットワークワーキンググループ。
- HTML Living Standard で定義されているHTMLの仕様。 Web Hypertext Application Technology Working Group （WHATWG）によって作成されています。 W3Cは、この標準のさまざまなバージョンを再公開およびフォークし、他のバージョンの中で HTML 4 、 XHTML 1. 、および HTML5 としてリリースします。 WHATWGはこれを行うことに不満を持っています。
- Javaには、Oracleによって維持されている標準があります。そのさまざまなバージョンには異なる標準があり、あなたは Java EE 7標準 をダウンロードできます。
- C＃言語仕様5. 、Microsoftのチームによって作成されました。以前のバージョンには、独自の個別の仕様書があります。
HTMLは、言語のバージョンによって規格が異なることがよくあるという良い例です。さまざまなバージョンには、言語のさまざまなバージョンをどのように処理する必要があるかを説明するさまざまなドキュメントがあります。
一方、HTTPは、標準的な移動betweenグループの多くの例の1つです。最初はネットワークワーキンググループ、次にHTTPワーキンググループに移動します。どちらのグループもIETFの一部でした。他のテクノロジーは企業間を移動しましたHTMLなど（再び）、バージョン2は IETFによってRFC1866で作成されました 。
なぜ標準が存在するのですか？
それらは、物事がどのように機能するかを保証するために存在します。
HTML5仕様は、標準が正しく実装されている（これまで問題となっていた）と仮定して、さまざまなブラウザがHTML5マークアップを処理して表示する方法を教えてくれます。 C++ 11標準は、私が書くさまざまなC++ 11コードが何をするか、何をしないかについて教えてくれます。
同様に、私がwriteブラウザーである場合、HTML5標準は、人々がそれらを得るようにHTML5マークアップのさまざまな部分を処理する必要がある方法を教えてくれます期待しています。 C++ 11コンパイラを作成している場合、C++ 11標準は、言語を正しく実装し、人々のコードを期待どおりに機能させるために何をする必要があるかを教えてくれます。
たとえば、MicrosoftはC＃を作成しています。 C＃言語仕様5. をダウンロードできます。このドキュメントは、作成するC＃コードが、仕様を実際に正しく実装するすべてのコンパイラーで、仕様に記述されているとおりに動作することを約束しています。
（ 仕様外のことを行う場合 、未定義の領域にいるため、何が起こるか、何が起こらないかについては何の保証もありません。）
歴史的に、標準は ねじ山 のようなものに戻っているので、タイプXのねじを注文した場合、ドリルした穴に適合し、交換可能であることを保証できますタイプXの他のネジを使用します。
単語「標準」の定義 に戻ります。
他の人が判断または測定される対象となる、承認または承認された例—Collins辞書
定量的または定性的な値の比較の認められた尺度。基準。 —AmericanHeritage®Stedman's Medical Dictionary
つまり、あなたが自分のものを比較して、期待どおりの結果が得られることを確認するものです。
テクノロジー標準は、同じ標準の2つの実装が相互運用可能または交換可能であることが期待されるような仕様です。例：USB、Bluetooth、Java EE7、HTTP。
「デファクト」標準があります：相互運用性を可能にする規約ですが、明示的に合意された仕様はありません。例：Microsoft DOC形式は、歴史的にデファクトスタンダードでした、多くの製品はDOCを読み書きできましたが、標準的な仕様は利用できませんでした（かなり後になるまで）。文書は依然としてDOC形式で一般的に配布されていましたが、どの受信者もそれを読むことができると予想されていたため、事実上の標準になりました。
特定の例に対処するために、RESTは明示的に合意された仕様を持たないため、真の標準ではなく、正しく実行する方法にかなりのあいまいさがあるため、ほとんど事実上の標準ではありません。これらのあいまいさを解決する主要な実装は存在しません。 （私はRESTに反対ではありません。これは、Webサービスを構築するための非常に良い方法です）
標準とは、標準化された規則です。形式的な仕様によるか、または単に共通の規則が優勢になるほどの人気を得ているためです。
de jure standardは、標準委員会によって公開された仕様です。 ISO、ECMA、DIN、ANSI、W3Cなどの標準委員会があります。
de jure standardsの例としては、A4用紙サイズ（ISO標準219）、c＃言語（ECMA-334）などがあります。
「de jure」という用語はめったに使用されず、「de jure標準」は単に標準と呼ばれることがよくあります。
デファクトスタンダードは、公衆の承認または市場の力によって支配的な地位を獲得したカスタム、慣習、製品、またはシステムです。」
（ソース： wikipedia -自分で書けなかった）
事実上の標準は、必ずしも正式な仕様に準拠しているわけではありません。
Gudmundur Ornが this answer で書いたように、Microsoft Office DOC形式は事実上の標準でした。これは支配的な立場であり、通常、人々が読むことができると想定されていましたMS Wordドキュメント。
JSONは、事実上の標準として始まったので、面白い動物です。しかし、それは ECMA-404 として正式化されたため、現在は「de jure standard」となっています。
ただし、これはHTTPベースのAPI（私の知る限り）とデータを交換するための主要な形式でもあるため、この目的の「事実上の標準」にもなっています。