私はJava EE 7を学び始めましたが、この「標準」という用語に頻繁に出くわしますが、その意味がわかりません。
W3C標準に依存するSOAPおよびWS- *スタックとは異なり、RESTには標準がなく、設計原則を備えたアーキテクチャのスタイルにすぎません。RESTアプリケーションは、他の多くの標準に大きく依存しています:HTTP、URI、URL ...
私はそれが何を意味するのかについていくつかの考えを持っていますが、私にはわかりません。
私はJava EE 7を学び始めましたが、この「標準」という用語に頻繁に出くわしますが、その意味がわかりません。
W3C標準に依存するSOAPおよびWS- *スタックとは異なり、RESTには標準がなく、設計原則を備えたアーキテクチャのスタイルにすぎません。RESTアプリケーションは、他の多くの標準に大きく依存しています:HTTP、URI、URL ...
私はそれが何を意味するのかについていくつかの考えを持っていますが、私にはわかりません。
回答:
プログラミングの「標準」という用語は、多くの場合、グループまたはコミュニティによって管理されるテクノロジー/ドキュメントを指します。そのグループのメンバーは、多くの場合、共通の投資目標を共有し、そのテクノロジーのアクティブユーザーであり、テクノロジーの継続を保証したいと考えています。
プログラミングには、それらを管理するコミュニティを持つ多くの「もの」があります。これらのメンバーは、プログラマーから企業の代表者(Apple、Microsoft、IBMなど)まで多岐にわたります。
W3Cは、多くの標準を定義するために協力する非常に大きなグループです。
メンバーのリストは次のとおりです。
http://www.w3.org/Consortium/Member/List
RESTは技術の例であり、その人気は多くの人々に使用されていますが、それを管理するグループやコミュニティはありません。したがって、指を指して「標準がそれを行うべきだと言っている」と言う場所はありません。
IBM、Microsoft、その他の企業は、RESTの実装方法に関するドキュメントを公開しています。RESTを実装する「一般的な方法」があると言えます。RESTの実装を説明する信頼できるソースを選択し、その参照に従うことを主張できます。信頼できるソースの使用は、Webブラウザーの互換性の問題に対処してきた1つの方法です。
標準とは、テクノロジーの動作を指定する技術文書です。(一部の技術では、他の種類の技術標準である可能性があります。)それがすべてであり、それらが存在する理由です。それらは文書であり、技術を説明しています。
これらの文書は、技術がどのように機能するかを決定するために必要な権限と信頼を持ち、標準として仕様文書をリリースするときに人々が気にかけるために必要な権限と信頼を持つ管理機関によって作成されます。統治体は、さまざまなテクノロジーまたはテクノロジーのさまざまなバージョンに対して、多くの標準を作成できます。統治体は、標準のメンテナー、著者、カストディアンなどとしても知られています。
(マシューは説明するものとは異なり、標準ではありません統治体も技術そのもの。それは、文書の記述技術、またはそれの特定のバージョンを。)
あなたが言及した技術の標準の例(およびその他):
HTMLは、言語のバージョンによって標準が異なることが多いという事実の良い例です。さまざまなバージョンには、さまざまなバージョンの言語を処理する方法を説明するさまざまなドキュメントがあります。
一方、HTTPは、グループ間を移動する標準の多くの例の1つです。最初はネットワークワーキンググループによって、次にHTTPワーキンググループに移動しますが、どちらのグループもIETFの一部でした。HTML(再度)など、RFC1866のIETFによって作成されたバージョン2など、他の技術も企業間を移動しました。
これらは、物事がどのように機能するかを保証するために存在します。
HTML5仕様では、さまざまなブラウザーが標準を正しく実装していることを前提に、筆者が記述したHTML5マークアップを処理および表示する方法を教えてくれます(これまでは問題でした)。C ++ 11標準は、私が書くさまざまなC ++ 11コードが何をするか、またはしないかについて教えてくれます。
同様に、私がブラウザを書いている場合、HTML5標準は、人々が期待するものを得るために、HTML5マークアップのさまざまな部分を処理する方法を教えてくれます。C ++ 11コンパイラを書いている場合、C ++ 11標準は、言語を正しく実装し、人々のコードが期待どおりに機能するようにするために必要なことを教えてくれます。
たとえば、MicrosoftはC#を作成しています。C#言語仕様5.0は自分でダウンロードできます。このドキュメントは、仕様を実際に正しく実装するコンパイラで、作成するC#コードが仕様で記述されているとおりに動作することを約束します。
(仕様以外のことを行うと、未定義の領域にいることになり、何が起こるか、または起こらないかについての保証はありません。)
歴史的に、標準はネジ山のようなものに戻っているため、タイプXのネジを注文すると、ドリルした穴に適合し、タイプXの他のネジと交換できることを保証できます。
「標準」という言葉の定義に戻ります。
他人が判断または測定される対象の容認または承認された例— Collins Dictionary
定量的または定性的価値の認められた比較尺度。基準。— AmericanHeritage®ステッドマン医学辞典
すなわち、あなたがあなたが期待するものを確実に手に入れるために、あなたのものを比較するもの。
技術標準は、同じ標準の2つの実装が相互運用可能または交換可能であることが期待されるような仕様です。例:USB、Bluetooth、Java EE7、HTTP。
次に、「事実上の」標準があります。相互運用性を可能にする規則ですが、明示的に合意された仕様はありません。例:多くの製品がDOCを読み書きできるので、Microsoft DOC形式は歴史的に事実上の標準でしたが、標準仕様は(かなり後まで)利用できませんでした。文書は一般にDOC形式で配布されていましたが、どの受信者でも読むことができると予想されていたため、事実上の標準になりました。
あなたの特定の例に対処するために、RESTには明示的に合意された仕様がなく、したがって真の標準ではなく、正しく行う方法にかなりの曖昧性があり、支配的な実装が存在しないため、事実上の標準ではありませんこれらのあいまいさを解決します。(私はRESTに反対ではありません。Webサービスを構築するのに非常に良い方法です)
標準は標準化された規則です-正式な仕様によるか、単に一般的な規則が十分な人気を獲得したためです。
A de jure standard
は、標準委員会によって発行された仕様です。一部の標準委員会は、ISO、ECMA、DIN、ANSI、およびW3Cです。
たとえば de jure standards
、A4用紙サイズ(ISO標準219)、c#言語(ECMA-334)などです。
「de jure」という用語はめったに使用されず、「de jure standard」はしばしば単に標準と呼ばれます。
事実上の標準とは、一般の受け入れや市場の力によって支配的な地位を獲得したカスタム、慣習、製品、またはシステムです」
(ソース:ウィキペディア -自分でもっとうまく書けなかった)
事実上の標準は、必ずしも正式な仕様に従うとは限りません。
Gudmundur Ornがこの回答で書いたように、Microsoft Office DOC形式は事実上の標準でした。支配的な地位にあり、通常は人々がMS Word文書を読むことができると想定されていました。
JSONは事実上の標準として始まったため、面白い獣です。しかし、それはその後ECMA-404として正式化されたため、今では「デジュレ標準」になっています。
ただし、これは(私の知る限り)HTTPベースのAPIとデータを交換するための主要な形式でもあるため、この目的の「事実上の標準」にもなっています。
法的製造物責任については、欠陥は設計、製造、または文書に分類されます。規格に基づいている場合、その規格に欠陥があるかどうかに関係なく、設計に欠陥はありません。適用される標準は、製品の作成時に設定されたものです。標準は、公開された標準(ISO)または標準協会によって公開されていない業界標準として認められています。したがって、スプーフィングのような固有の欠陥をすべて備えたTCP / IPは標準であり、VOIPのような新しいテクノロジーを作成し、基礎となるテクノロジーの既知の問題からユーザーを保護するために何もしなければ、騒乱を続けても安全です。または私は間違っている可能性があり、ここにドキュメントの欠陥があります...