Я начал изучать Java EE 7, и я часто сталкиваюсь с этим термином «стандарт», и я не понимаю, что это значит.
Так, например, вот цитата из этой книги:
В отличие от SOAP и стека WS- *, которые опираются на стандарты W3C, REST не имеет стандарта и представляет собой просто стиль архитектуры с принципами проектирования. Приложения REST сильно зависят от многих других стандартов: HTTP, URI, URL ...
У меня есть представление о том, что это может значить, но я не уверен.
Лучшее объяснение, с которым я столкнулся, - это определение отсюда .
coding-standards
standards
Джоле Пи
источник
источник
Ответы:
Термин «стандарты» в программировании часто относится к технологии / документу, который регулируется группой или сообществом. Члены этой группы часто разделяют общие поставленные цели, являются активными пользователями этой технологии и хотят, чтобы технология продолжалась.
В программировании есть много «вещей», которые управляют ими. Эти члены могут варьироваться от программистов до корпоративного представительства (например, Apple, Microsoft, IBM и т. Д. И т. Д.)
W3C - очень большая группа, которая работает вместе, чтобы определить множество стандартов.
Вот список участников.
http://www.w3.org/Consortium/Member/List
REST является примером технологии, которая популярна среди многих людей, но не существует группы или сообщества, управляющих ею. Поэтому нет единого места, где можно было бы указать пальцем и сказать: «Так говорят стандарты, это должно быть сделано» .
Такие компании, как IBM, Microsoft и другие опубликовали документацию о том, как реализовать REST. Можно сказать, что существует «общий способ» реализации REST. Вы можете выбрать авторитетный источник, который описывает реализацию REST, и заявить, что следует этой ссылке. Использование авторитетных источников является одним из способов решения проблем совместимости в веб-браузерах.
источник
Стандарт - это технический документ, определяющий, как ведет себя технология. (Для некоторых технологий это может быть какой-то другой технический стандарт .) Это все, что они есть и почему они существуют: это документы, и они описывают технологию.
Эти документы созданы руководящим органом, который обладает полномочиями и доверием, необходимыми для того, чтобы они могли принимать решение о том, как работает эта технология, и чтобы люди были обеспокоены, когда выпускают документ спецификации в качестве стандарта. Управляющий орган может разработать множество стандартов для разных технологий или разных версий технологии. Руководящий орган также может быть известен как сопровождающие, авторы, хранители и т. Д. Стандартов.
(В отличие от того, что описывает Мэтью, стандарт не является ни руководящим органом, ни самой технологией. Это документ, описывающий технологию, или ее конкретную версию.)
Некоторые примеры стандартов для технологий, которые вы упомянули (и другие):
HTML является хорошим примером того, что разные версии языка часто имеют разные стандарты. Различные версии имеют разные документы, описывающие, как должны обрабатываться различные версии языка.
HTTP, между тем, является одним из многих примеров стандартного перемещения между группами: сначала Сетевой рабочей группой, затем - Рабочей группой HTTP, хотя обе группы были частью IETF. Другие компании переместились между компаниями, например HTML (опять же), версия 2 которого была создана IETF в RFC1866 .
Почему существуют стандарты?
Они существуют, чтобы дать нам гарантию того, как все будет работать.
Спецификация HTML5 говорит мне, как различные браузеры будут обрабатывать и отображать разметку HTML5, которую я пишу, при условии, что они правильно реализуют стандарт (что исторически было проблемой). Стандарт C ++ 11 расскажет мне о том, что будет делать или не писать код на C ++ 11, который я пишу.
Аналогично, если я пишу браузер, стандарт HTML5 скажет мне, как мне нужно обрабатывать различные фрагменты HTML5-разметки, чтобы люди получали то, что ожидали. Если я пишу компилятор C ++ 11, стандарт C ++ 11 скажет мне, что мне нужно сделать, чтобы правильно реализовать язык и заставить код людей работать так, как они ожидают.
Например, авторы Microsoft C #. Вы можете скачать C # Language Specification 5.0 для себя. Этот документ обещает, что код C #, который вы пишете, должен вести себя так, как он описан в спецификации, в любом компиляторе, который фактически реализует спецификацию правильно.
( Если вы делаете что-то за пределами спецификации , вы находитесь на неопределенной территории, и нет никаких гарантий относительно того, что произойдет или не произойдет.)
Исторически стандарты возвращаются к таким вещам, как винтовая резьба , так что я могу иметь некоторую гарантию, что, если я закажу винт типа X, он будет соответствовать отверстию, которое я просверлил, и будет взаимозаменяем с другими винтами типа X.
Что возвращает нас к определению слова «стандарт» :
то есть то, с чем вы сравниваете свои вещи, чтобы убедиться, что вы получите то, что ожидаете.
источник
Технологический стандарт - это такая спецификация, что ожидается, что две реализации одного и того же стандарта будут совместимы или взаимозаменяемы. Примеры: USB, Bluetooth, Java EE7, HTTP.
Кроме того, существуют стандарты «де-факто»: соглашения, обеспечивающие совместимость, но без явной согласованной спецификации. Пример: формат Microsoft DOC исторически был стандартом де-факто, поскольку многие продукты могли читать и записывать DOC, но канонические спецификации были недоступны (намного позже). Документы по-прежнему широко распространялись в формате DOC, и ожидалось, что любой получатель сможет их прочитать, поэтому это стало стандартом де-факто.
Чтобы обратиться к вашему конкретному примеру, REST не имеет явной согласованной спецификации и поэтому не является истинным стандартом, а лишь стандартом де-факто, поскольку имеет значительную неоднозначность в том, как это должно быть сделано правильно, и не существует доминирующих реализаций, разрешает эти неясности. (Я не против REST. Это очень хороший способ создания веб-сервисов)
источник
Стандарт - это стандартизированное соглашение - либо по формальной спецификации, либо просто потому, что общее соглашение приобрело достаточную популярность, чтобы быть доминирующим.
A
de jure standard- спецификация, опубликованная стандартным комитетом. Некоторые стандартные комитеты: ISO, ECMA, DIN, ANSI и W3C.Примерами
de jure standardsмогут служить формат бумаги A4 (стандарт ISO 219), язык c # (ECMA-334) и т. Д.Термин «де-юре» используется редко, а «стандарт де-юре» часто называют просто стандартом.
(источник: Википедия - я не мог бы написать лучше)
Стандарт де-факто не обязательно следует какой-либо формальной спецификации.
Как писал в этом ответе Гудмундур Орн, формат Microsoft Office DOC был стандартом де-факто. Он занимал доминирующее положение, и обычно предполагалось, что люди могут читать документы MS Word.
JSON - забавный зверь, поскольку он начинал как стандарт де-факто. Однако с тех пор он был официально оформлен как ECMA-404 , поэтому теперь он является стандартом де-юре.
Однако он также является преобладающим форматом для обмена данными с API на основе HTTP (насколько мне известно), что делает его также «стандартом де-факто» для этой цели.
источник
Для юридической ответственности за продукт дефект относится к дизайну, изготовлению или документации. Конструкция не является дефектной, если она основана на стандарте, независимо от того, является ли этот стандарт дефектным. Применяется стандарт, который применяется при создании продукта. Стандарт может быть опубликованным стандартом (ISO) или принятым отраслевым стандартом, который не публикуется ассоциацией стандартов. Таким образом, TCP / IP со всеми присущими ему дефектами, такими как спуфинг, является стандартом, и если вы создаете новую технологию, такую как VOIP, и ничего не делаете для защиты пользователя от известных проблем с базовой технологией, вы можете продолжать беспорядки. Или я могу ошибаться и иметь дефект документации здесь ...
источник