Bazı teknolojilerin “standart” olması ne anlama gelir?

Java EE 7 öğrenmeye başladım ve sık sık bu "standart" terimiyle karşılaşıyorum ve bunun ne anlama geldiğini anlamıyorum.

Örneğin, bu kitaptan bir alıntı :

SOAP ve W3C standartlarına dayanan WS- * yığınının aksine, REST'in bir standardı yoktur ve sadece tasarım ilkelerine sahip bir mimari tarzıdır. REST uygulamaları diğer birçok standarda dayanmaktadır: HTTP, URI, URL ...

Bunun ne anlama gelebileceğine dair bir fikrim var, ama emin değilim.

Karşılaştığım en iyi açıklama buradan gelen tanım .

Programlamadaki "standartlar" terimi genellikle bir grup veya topluluk tarafından yönetilen bir teknolojiye / belgeye karşılık gelir. Bu grubun üyeleri genellikle ortak yatırım hedeflerini paylaşır, bu teknolojinin aktif kullanıcılarıdır ve teknolojinin devam etmesini sağlamak isterler.

Programlamada onları yöneten bir topluluğa sahip birçok "şey" vardır. Bu üyeler programcılardan kurumsal temsilciliğe kadar değişebilir (örneğin Apple, Microsoft, IBM, vb.)

W3C, birçok standardı tanımlamak için birlikte çalışan çok büyük bir gruptur.

İşte üyelerin listesi.

http://www.w3.org/Consortium/Member/List

REST, teknolojinin bir örneğidir, popülerliği nedeniyle birçok kişi tarafından kullanılır, ancak onu yöneten bir grup veya topluluk yoktur. Bu nedenle, bir parmağı işaret edip "standartların bu şekilde yapılması gerektiğini söyler " diyecek tek bir yer yoktur .

IBM, Microsoft ve diğerleri gibi şirketler, REST'in nasıl uygulanacağına dair belgeler yayınladılar. REST'in uygulanmasının "ortak bir yolu" olduğu söylenebilir. Bir REST uygulamasını açıklayan yetkili bir kaynak seçebilir ve bu referansı izlemeyi talep edebilirsiniz. Yetkili kaynakların kullanımı, web tarayıcılarındaki uyumluluk sorunlarıyla ilgilenmemizin bir yoludur.

Standart, bir teknolojinin nasıl davrandığını belirten teknik bir belgedir. (Bazı teknolojiler için, bu başka bir tür teknik standart olabilir .) Hepsi bu ve neden varlar: belgelerdir ve teknolojiyi tanımlarlar.

Bu belgeler, teknolojinin nasıl çalıştığına karar verebilmeleri için gereken yetki ve güveye sahip olan ve standart olarak bir spesifikasyon belgesini yayınladıklarında ilgilenecekleri kişiler tarafından yönetilir. Yönetim organı, farklı teknolojiler veya teknolojinin farklı sürümleri için birçok standart üretebilir. Yönetim organı ayrıca standartların koruyucular, yazarlar, velayetler, vb. Olarak da bilinir.

(Mathew tanımladığı şeye Kontrast, bir standarttır değil yönetim organı ne de teknoloji kendisi. Bu bir belge olduğunu açıklayan teknoloji, ya da belirli bir sürümünü.)

Bahsettiğiniz teknolojiler (ve diğerleri) için bazı örnek standartlar:

• W3C tarafından sağlanan SOAP standardı.
• STD66'da tanımlanan URI standardı, İnternet Mühendisliği Görev Gücü (IETF) tarafından da sürdürülmekte ve aynı zamanda ...
• HTTP 1.1 Özellikleri , tarafından kaleme HTTP Çalışma Grubu . Bunlar Yorum Talepleri'dir (RFC), ancak yine de HTTP'nin nasıl çalıştığını belirtin. Bu standartlar aslında çok yeni , sadece Haziran 2014'te piyasaya sürüldü. HTTP 1.1 daha önce RFC 2616'da IETF Network Working Group tarafından tanımlanmıştı .
• HTML Yaşam Standardında tanımlanan HTML özellikleri . Web Köprü Metni Uygulama Teknolojisi Çalışma Grubu (WHATWG) tarafından yazılmıştır . W3C, bu standardın çeşitli sürümlerini yeniden yayınlar ve çatallar , diğer sürümler arasında HTML 4 , XHTML 1.0 ve HTML5 olarak serbest bırakır . WHATWG bunu yapma konusunda mutsuz.
• Java, Oracle tarafından korunan bir standarda sahiptir. Çeşitli sürümleri farklı standartlara sahiptir ve Java EE 7 standardını kendiniz indirebilirsiniz .
• Microsoft'ta bir ekip tarafından yazılan C # Dil Spesifikasyonu 5.0 . Önceki sürümlerin kendi ayrı spesifikasyon belgeleri vardır.

HTML, bir dilin farklı sürümlerinin genellikle farklı standartlara sahip olacağına iyi bir örnektir. Çeşitli sürümler, dilin çeşitli sürümlerinin nasıl ele alınması gerektiğini açıklayan farklı belgelere sahiptir.

Bu arada HTTP, gruplar arasında hareket eden bir çok standardın örneğidir : önce Ağ Çalışma Grubu tarafından, daha sonra her iki grup da IETF'nin bir parçası olmasına rağmen HTTP Çalışma Grubuna. Diğer teknolojiler , örneğin 2'si RFC1866'da IETF tarafından yazılan HTML (tekrar) gibi şirketler arasında taşındı .

Standartlar neden var?

Bize işlerin nasıl çalışacağına dair bir garanti vermek için varlar.

HTML5 özelliği, standardın doğru bir şekilde uygulandığını varsayarak (geçmişte bir sorun olmuştur) çeşitli tarayıcıların yazdığım HTML5 işaretlemesini nasıl işleyeceğini ve görüntüleyeceğini anlatıyor. C ++ 11 standardı, yazdığım çeşitli C ++ 11 kodunun ne yapacağını veya yapmayacağını söyleyecek.

Benzer şekilde, bir tarayıcı yazıyorsam , HTML5 standardı, insanların bekledikleri şeyi elde edebilmeleri için çeşitli HTML5 işaretlemelerini nasıl ele almam gerektiğini söyleyecektir. Bir C ++ 11 derleyicisi yazıyorsam, C ++ 11 standardı bana dili doğru bir şekilde uygulamak ve insanların kodlarının çalışmasını bekledikleri şekilde çalışmasını sağlamak için ne yapmam gerektiğini söyleyecek.

Örneğin, Microsoft C # yazar. C # Dil Spesifikasyonu 5.0'ı kendiniz indirebilirsiniz . Bu belge, yazdığınız C # kodunun, belirtimi doğru şekilde uygulayan herhangi bir derleyicide belirtimde açıklandığı şekilde davranması gerektiğine dair bir vaattir.

( Spesifikasyonun dışında bir şeyler yaparsanız, tanımlanmamış bir bölgedesiniz ve ne olacağı veya olmayacağı konusunda hiçbir garanti yoktur.)

Tarihsel olarak, standartlar vida dişleri gibi şeylere geri döner , böylece X tipi bir vida sipariş edersem, deldiğim deliğe sığacağını ve X tipi diğer vidalarla değiştirilebileceğini garanti edebilirim.

Bu da bizi "standart" kelimesinin tanımına geri getiriyor :

başkalarının yargıladığı veya ölçüldüğü bir şeyin kabul edilmiş veya onaylanmış bir örneği - Collins Dictionary

Nicel veya nitel değer için kabul edilmiş bir karşılaştırma ölçüsü; bir kriter. - American Heritage® Stedman'ın Tıbbi Sözlüğü

beklediğiniz şeyi elde emin olmak için şeyler karşılaştırmak şey yani.

Bir teknoloji standardı, aynı standarttaki iki uygulamanın birlikte çalışabilir veya birbiriyle değiştirilebilir olması beklenen bir spesifikasyondur. Örnekler: USB, Bluetooth, Java EE7, HTTP.

Daha sonra "fiili" standartlar vardır: birlikte çalışabilirliği mümkün kılan, ancak üzerinde anlaşmaya varılan açık bir şartname olmaksızın sözleşmeler. Örnek: Microsoft DOC formatı geçmişte fiili bir standart olmuştur, çünkü birçok ürün DOC okuyabilir ve yazabilir, ancak kanonik özellikler mevcut değildi (çok daha sonraya kadar). Belgeler hala herhangi bir alıcının okuyabileceği beklentisi ile DOC formatında yaygın olarak dağıtıldı, böylece fiili bir standart haline gelmişti.

Spesifik örneğinizi ele almak için, REST'in üzerinde anlaşmaya varılmış açık bir spesifikasyonu yoktur ve bu nedenle doğru bir standart değildir ve fiilen bir standart değildir, çünkü doğru bir şekilde nasıl yapılması gerektiği konusunda önemli belirsizliğe sahiptir ve bu belirsizlikleri çözer. (REST'e karşı değilim. Web hizmetleri oluşturmanın çok iyi bir yolu)

Standart, standart bir sözleşmedir - ya resmi bir şartnameyle ya da sadece ortak bir sözleşmenin baskın olacak kadar popülerlik kazanması nedeniyle.

A de jure standard, standart bir komite tarafından yayınlanan bir spesifikasyondur. Bazı standart komiteler ISO, ECMA, DIN, ANSI ve W3C'dir.

Bazı örnekler de jure standards (ECMA-334), vb A4 kağıt boyutu (ISO standardı 219), c # dili vardır

'De jure' terimi nadiren kullanılır ve 'de jure standardı' genellikle sadece standart olarak adlandırılır.

Fiili standart kamuoyu kabulü veya piyasa güçleri tarafından baskın bir konuma sahip olan bir gelenek, sözleşme, ürün veya sistemdir "

(kaynak: wikipedia - Kendim daha iyi yazamadım)

Bir fiili standart zorunlu olarak herhangi bir resmi spesifikasyona uymaz.

Gudmundur Orn'ın bu cevapta yazdığı gibi , Microsoft Office DOC formatı fiili bir standarttı. Baskın bir konuma sahipti ve normalde insanların MS Word belgelerini okuyabileceği varsayıldı.

JSON fiili bir standart olarak başladığı için komik bir canavar. Ancak o zamandan beri ECMA-404 olarak resmileştirildi , bu yüzden şimdi bir 'de jure standardı'.

Bununla birlikte, HTTP tabanlı API'lerle veri alışverişinde (bildiklerime göre) baskın formattır, bu da onu 'fiili standart' haline getirir.

Yasal ürün yükümlülüğü için kusur tasarım, üretim veya dokümantasyon olarak sınıflandırılır. Bir tasarım, bir standarda dayanıyorsa, bu standardın kusurlu olup olmadığına bakılmaksızın kusurlu değildir. Geçerli standart, ürünün yaratıldığı zamandır. Standart, yayınlanmış bir standart (ISO) veya standart birliği tarafından yayınlanmamış kabul edilmiş bir endüstri standardı olabilir. Kimlik sahtekarlığı gibi tüm doğal kusurları ile TCP / IP standarttır ve VOIP gibi yeni bir teknoloji oluşturursanız ve kullanıcıyı altta yatan teknoloji ile ilgili bilinen sorunlardan korumak için hiçbir şey yapmazsanız, kargaşaya devam edebilirsiniz. Ya da yanılıyor olabilirim ve burada bir doküman hatası var ...