Điều đó có nghĩa là gì khi một số công nghệ là một tiêu chuẩn của người Viking?

Tôi bắt đầu học Java EE 7 và tôi thường xuyên bắt gặp thuật ngữ "tiêu chuẩn" này và tôi không hiểu ý nghĩa của nó.

Vì vậy, ví dụ, đây là một trích dẫn từ cuốn sách này :

Trái ngược với SOAP và ngăn xếp WS- *, dựa trên các tiêu chuẩn W3C, REST không có tiêu chuẩn và chỉ là một phong cách kiến ​​trúc với các nguyên tắc thiết kế. Các ứng dụng REST phụ thuộc rất nhiều vào các tiêu chuẩn khác: HTTP, URI, URL ...

Tôi có một số ý tưởng về điều đó có nghĩa là gì, nhưng tôi không chắc chắn.

Giải thích tốt nhất mà tôi đã đi qua là định nghĩa từ đây .

Thuật ngữ "tiêu chuẩn" trong lập trình thường dùng để chỉ một công nghệ / tài liệu được điều chỉnh bởi một nhóm hoặc cộng đồng. Các thành viên của nhóm đó thường chia sẻ các mục tiêu đầu tư chung, là những người dùng tích cực của công nghệ đó và muốn đảm bảo công nghệ tiếp tục.

Có nhiều "điều" trong lập trình có một cộng đồng chi phối chúng. Các thành viên này có thể bao gồm từ lập trình viên đến đại diện công ty (ví dụ: Apple, Microsoft, IBM, v.v.)

W3C là một nhóm rất lớn làm việc cùng nhau để xác định nhiều tiêu chuẩn.

Dưới đây là danh sách các thành viên.

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

REST là một ví dụ về công nghệ, bằng cách phổ biến nó được sử dụng bởi nhiều người, nhưng không có nhóm hoặc cộng đồng nào quản lý nó. Do đó, không có nơi nào để chỉ tay và nói "đó là cách các tiêu chuẩn nói rằng nó nên được thực hiện" .

Các công ty như IBM, Microsoft và các công ty khác đã xuất bản tài liệu về cách triển khai REST. Người ta có thể nói có một "cách chung" để thực hiện REST. Bạn có thể chọn một nguồn có thẩm quyền mô tả việc triển khai REST và yêu cầu tuân theo tham chiếu đó. Việc sử dụng các nguồn có thẩm quyền là một cách chúng tôi đã xử lý các vấn đề về tính tương thích trong các trình duyệt web.

Một tiêu chuẩn là một tài liệu kỹ thuật chỉ định cách thức hoạt động của công nghệ. (Đối với một số công nghệ, nó có thể là một số loại tiêu chuẩn kỹ thuật khác .) Đó là tất cả chúng là và tại sao chúng tồn tại: chúng là tài liệu và chúng mô tả công nghệ.

Các tài liệu này được ủy quyền bởi một cơ quan quản lý có thẩm quyền và sự tin cậy cần thiết để họ có thể quyết định công nghệ đó hoạt động như thế nào và mọi người quan tâm khi họ phát hành một tài liệu đặc tả như một tiêu chuẩn. Một cơ quan quản lý có thể sản xuất nhiều tiêu chuẩn, cho các công nghệ khác nhau hoặc các phiên bản khác nhau của công nghệ. Cơ quan quản lý cũng có thể được gọi là người duy trì, tác giả, người giám sát, vv của các tiêu chuẩn.

(Trái ngược với những gì Mathew mô tả, một tiêu chuẩn không phải là cơ quan quản lý cũng không phải là chính công nghệ. Đó là một tài liệu mô tả công nghệ hoặc một phiên bản cụ thể của nó.)

Một số tiêu chuẩn mẫu cho các công nghệ bạn đã đề cập (và các tiêu chuẩn khác):

• Các SOAP tiêu chuẩn, được duy trì bởi W3C.
• Tiêu chuẩn URI, được xác định trong STD66 , được duy trì bởi Lực lượng đặc nhiệm kỹ thuật Internet (IETF), người cũng làm việc trên ...
• Các HTTP 1.1 Thông số kỹ thuật , tác giả của các Nhóm công tác HTTP . Đây là những Yêu cầu Nhận xét (RFC), tuy nhiên chỉ định cách thức hoạt động của HTTP. Các tiêu chuẩn này thực sự rất mới , chỉ được phát hành vào tháng 6 năm 2014. HTTP 1.1 đã được xác định trước đây trong RFC 2616 , bởi Nhóm làm việc mạng IETF.
• Thông số kỹ thuật của HTML, được xác định trong Tiêu chuẩn sống HTML . Nó được tác giả bởi Nhóm làm việc về công nghệ ứng dụng siêu văn bản Web (WHATWG). W3C tái xuất bản và tạo ra các phiên bản khác nhau của tiêu chuẩn này, phát hành chúng dưới dạng HTML 4 , XHTML 1.0 và HTML5 trong số các phiên bản khác. WHATWG không hài lòng về việc họ làm điều này.
• Java có một tiêu chuẩn, được duy trì bởi Oracle. Các phiên bản khác nhau của nó có các tiêu chuẩn khác nhau và bạn có thể tự tải xuống tiêu chuẩn Java EE 7 .
• Đặc tả ngôn ngữ C # 5.0 , được soạn thảo bởi một nhóm tại Microsoft. Các phiên bản trước có tài liệu đặc điểm kỹ thuật riêng của họ.

HTML là một ví dụ điển hình về thực tế là các phiên bản khác nhau của ngôn ngữ thường sẽ có các tiêu chuẩn khác nhau. Các phiên bản khác nhau có các tài liệu khác nhau mô tả cách xử lý các phiên bản khác nhau của ngôn ngữ.

Trong khi đó, HTTP là một trong nhiều ví dụ về việc di chuyển tiêu chuẩn giữa các nhóm: đầu tiên là Nhóm làm việc mạng, sau đó đến Nhóm làm việc HTTP, mặc dù cả hai nhóm đều là một phần của IETF. Các công nghệ khác đã được chuyển giữa các công ty, chẳng hạn như HTML (một lần nữa), phiên bản 2 trong số đó được IETF là tác giả trong RFC1866 .

Tại sao các tiêu chuẩn tồn tại?

Chúng tồn tại để cho chúng ta một sự đảm bảo về cách mọi thứ sẽ hoạt động.

Đặc tả HTML5 cho tôi biết các trình duyệt khác nhau sẽ xử lý và hiển thị đánh dấu HTML5 mà tôi viết như thế nào, giả sử họ thực hiện đúng tiêu chuẩn (điều này trước đây là một vấn đề). Tiêu chuẩn C ++ 11 sẽ cho tôi biết những điều về những mã C ++ 11 khác nhau mà tôi viết sẽ hoặc sẽ không làm.

Tương tự, nếu tôi đang viết một trình duyệt, tiêu chuẩn HTML5 sẽ cho tôi biết tôi cần xử lý các phần đánh dấu HTML5 khác nhau như thế nào để mọi người có được những gì họ mong đợi. Nếu tôi đang viết trình biên dịch C ++ 11, tiêu chuẩn C ++ 11 sẽ cho tôi biết những gì tôi cần làm để thực hiện ngôn ngữ một cách chính xác và để mã của mọi người hoạt động theo cách họ mong đợi nó hoạt động.

Chẳng hạn, tác giả Microsoft C #. Bạn có thể tải xuống Đặc tả ngôn ngữ C # 5.0 cho chính mình. Tài liệu này là một lời hứa rằng mã C # bạn viết phải hành xử theo cách nó được mô tả trong đặc tả, trong bất kỳ trình biên dịch nào thực sự thực hiện chính xác đặc tả.

( Nếu bạn làm những việc bên ngoài đặc điểm kỹ thuật , bạn đang ở trong lãnh thổ không xác định và không có gì đảm bảo về những gì sẽ hoặc sẽ không xảy ra.)

Về mặt lịch sử, các tiêu chuẩn quay trở lại những thứ như ren vít , do đó tôi có thể đảm bảo rằng nếu tôi đặt mua một loại vít loại X, nó sẽ vừa với lỗ tôi đã khoan và sẽ có thể hoán đổi với các ốc vít loại X khác.

Điều này đưa chúng ta trở lại định nghĩa của từ "tiêu chuẩn" :

một ví dụ được chấp nhận hoặc phê duyệt về một cái gì đó mà người khác được đánh giá hoặc đo lường - Từ điển Collins

Một biện pháp so sánh được thừa nhận cho giá trị định lượng hoặc định tính; một tiêu chí. - Từ điển y khoa của American Heritage® Stedman

tức là thứ bạn so sánh công cụ của bạn để đảm bảo bạn sẽ nhận được những gì bạn mong đợi.

Một tiêu chuẩn công nghệ là một đặc điểm kỹ thuật sao cho hai triển khai của cùng một tiêu chuẩn được dự kiến ​​là có thể tương tác hoặc hoán đổi cho nhau. Ví dụ: USB, Bluetooth, Java EE7, HTTP.

Sau đó, có các tiêu chuẩn "thực tế": các quy ước cho phép khả năng tương tác, nhưng không có thông số kỹ thuật theo thỏa thuận rõ ràng. Ví dụ: Định dạng Microsoft DOC trong lịch sử là một tiêu chuẩn thực tế, vì nhiều sản phẩm có thể đọc và viết DOC, nhưng các thông số kỹ thuật chính tắc không có sẵn (cho đến sau này rất nhiều). Các tài liệu vẫn thường được phân phối theo định dạng DOC, với mong muốn rằng bất kỳ người nhận nào cũng có thể đọc nó, do đó nó đã trở thành một tiêu chuẩn thực tế.

Để giải quyết ví dụ cụ thể của bạn, REST không có thông số kỹ thuật theo thỏa thuận rõ ràng và do đó không phải là một tiêu chuẩn thực sự và hầu như không phải là một tiêu chuẩn thực tế vì nó có sự mơ hồ đáng kể về cách thực hiện chính xác và không có triển khai chi phối nào tồn tại giải quyết những mơ hồ này. (Tôi không chống lại REST. Đây là một cách rất tốt để xây dựng các dịch vụ web)

Một tiêu chuẩn là một quy ước được tiêu chuẩn hóa - hoặc bởi một đặc điểm kỹ thuật chính thức, hoặc đơn giản là vì một quy ước chung đã có đủ sự phổ biến để chiếm ưu thế.

A de jure standardlà một đặc điểm kỹ thuật được công bố bởi một ủy ban tiêu chuẩn. Một số ủy ban tiêu chuẩn là ISO, ECMA, DIN, ANSI và W3C.

Một số ví dụ về de jure standardskích thước giấy A4 (tiêu chuẩn ISO 219), ngôn ngữ c # (ECMA-334), v.v.

Thuật ngữ 'de jure' hiếm khi được sử dụng và 'tiêu chuẩn de jure' thường chỉ được gọi là tiêu chuẩn.

Một tiêu chuẩn thực tế là một tùy chỉnh, quy ước, sản phẩm hoặc hệ thống đã đạt được vị trí thống trị bởi sự chấp nhận của công chúng hoặc lực lượng thị trường "

(nguồn: wikipedia - Bản thân tôi không thể viết nó tốt hơn)

Một tiêu chuẩn thực tế không nhất thiết phải tuân theo bất kỳ đặc điểm kỹ thuật chính thức nào.

Như Gudmundur Orn đã viết trong câu trả lời này , định dạng Microsoft Office DOC là một tiêu chuẩn thực tế. Nó có một vị trí thống trị và thông thường người ta cho rằng mọi người có thể đọc tài liệu MS Word.

JSON là một con thú vui nhộn, vì nó bắt đầu như một tiêu chuẩn thực tế. Tuy nhiên, nó đã được chính thức hóa thành ECMA-404 , vì vậy giờ đây nó là một 'tiêu chuẩn'.

Tuy nhiên, đây cũng là định dạng chủ yếu để trao đổi dữ liệu với các API dựa trên HTTP (theo hiểu biết của tôi), do đó làm cho nó cũng trở thành 'tiêu chuẩn thực tế' cho mục đích này.

Đối với trách nhiệm pháp lý của sản phẩm, lỗi được phân loại là thiết kế, sản xuất hoặc tài liệu. Một thiết kế không bị lỗi nếu nó dựa trên một tiêu chuẩn, cho dù tiêu chuẩn đó có bị lỗi hay không. Tiêu chuẩn áp dụng là tại chỗ khi sản phẩm được tạo ra. Một tiêu chuẩn có thể là một tiêu chuẩn được công bố (ISO) hoặc một tiêu chuẩn công nghiệp được chấp nhận mà không được công bố bởi hiệp hội tiêu chuẩn. Vì vậy, TCP / IP với tất cả các khiếm khuyết vốn có của nó như giả mạo là một tiêu chuẩn và nếu bạn tạo ra một công nghệ mới như VOIP và không làm gì để bảo vệ người dùng khỏi các vấn đề đã biết với công nghệ cơ bản thì bạn có thể tiếp tục gặp rắc rối. Hoặc tôi có thể sai và có một khiếm khuyết tài liệu ở đây ...