I started learning Java EE 7 and I am frequently coming across this term "standard", and I don't understand what it means.

So, for example, here is a quotation from this book:

Contrary to SOAP and the WS-* stack, which rely on W3C standards, REST has no standard and is just a style of architecture with design principles. REST applications rely heavily on many other standards: HTTP, URI, URL...

I have some idea of what that might mean, but I'm not sure.

The best explanation that I have come across is the definition from here.


5 Answers 5


The term "standards" in programming often refers to a technology/document that is governed by a group or community. The members of that group often share common invested goals, are active users of that technology and want to ensure the technology continues.

There are many "things" in programming that have a community that governs them. These members can range from programmers to corporate representation (i.e. Apple, Microsoft, IBM, etc. etc.)

W3C is a very large group that work together to define many standards.

Here is a list of members.


REST is an example of a technology, by way of it's popularity is used by many people, but there is no group or community governing it. Therefore, there is no one place to point a finger and say "that's how the standards say it should be done".

Companies like IBM, Microsoft and others have published documentation of how to implement REST. One could say there is a "common way" of implementing REST. You can pick an authoritative source that describes an implementation of REST, and claim to follow that reference. The use of authoritative sources is one way we've been dealing with the problems of compatibility in web browsers.

  • 4
    I would also add RFC to the list of places to find standards, since e.g. HTTP which the asker mentioned is defined by RFC 2616
    – user22815
    Aug 31, 2014 at 22:36
  • 2
    @Snowman Keep in mind that not all RFCs are standards-track; I believe most are not. Also, as you can see up the top of your linked page, RFC 2616 is obsoleted by RFC 7230-7235, which should be referred to instead. Incidentally, that one is only a "Proposed Standard", not an "Internet Standard" (both are standards-track, but the latter is considered far more mature and unlikely to change).
    – Bob
    Aug 31, 2014 at 23:47
  • @Snowman: Your comment actually illustrates the most important thing: a standard is when people agree it's a standard. If you actually look at the RRF page, you will see that there are hundreds of RFCs, but actually only 78 standards. And HTTP, which you mentioned, is actually not a standard! It's "just" a Request For Comments, i.e. some idea that someone had which he wants discussed. The thing that makes HTTP a standard is not that some governing body publishes it (because the governing body in question, actually doesn't call it a "standard") but because people treat it as one. Sep 1, 2014 at 1:00
  • @JörgWMittag I've always taken a standard to be a document published from an authoritative source stating how something should be. The problem is people can disagree what an authoritative source is, while others abuse their authoritative powers (i.e. Microsoft and Apple are good examples). They both often ignore or try to force standards. Standards can often be something a large powerful corporation feels doesn't apply to them.
    – Reactgular
    Sep 1, 2014 at 1:14
  • 1
    @Mathew "I've always taken a standard to be a document published from an authoritative source stating how something should be." - I agree with this sentence in your comment, but your answer presently says the term 'standard' refers to the technology itself. (E.g. according to that, Java is a standard, the Java EE 7 spec isn't a standard.) The previous version said the organisations, such as Oracle or W3C, were what 'standard' meant. Your answer needs to be updated to say what you mean here. Written as is, your answer contains misinformation. :( Sep 1, 2014 at 4:44

A standard is a technical document specifying how a technology behaves. (For some technologies, it may be some other kind of technical standard.) That's all they are and why they exist: they are documents, and they describe the technology.

These documents are authored by a governing body which has the authority and trust necessary for them to be able to decide how that technology works, and for people to care when they release a specification document as a standard. A governing body could produce many standards, for different technologies or different versions of a technology. The governing body could also be known as maintainers, authors, custodians, etc of the standards.

(Contrast to what Mathew describes, a standard is not the governing body nor the technology itself. It's a document describing the technology, or a particular version of it.)

Some example standards for technologies you've mentioned (and others):

HTML is a good example of the fact that different versions of a language will often have different standards. The various versions have different documents describing how various versions of the language ought to be handled.

HTTP, meanwhile, is one of the many examples of a standard moving between groups: first by the Network Working Group, then to the HTTP Working Group, though both groups were part of the IETF. Other technologies have moved between companies, such as HTML (again), version 2 of which was authored by the IETF in RFC1866.

Why do standards exist?

They exist to give us a guarantee of how things will work.

The HTML5 specification tells me how the various browsers will handle and display the HTML5 markup I write, assuming they implement the standard correctly (which has historically been a problem). The C++11 standard will tell me things about what various C++11 code I write will or won't do.

Likewise, if I'm writing a browser, the HTML5 standard will tell me how I need to handle various pieces of HTML5 markup so that people get what they expect. If I'm writing a C++11 compiler, the C++11 standard will tell me what I need to do to implement the language correctly and get peoples' code working the way they expect it to work.

For instance, Microsoft authors C#. You can download the C# Language Specification 5.0 for yourself. This document is a promise that the C# code you write ought to behave the way it's described in the specification, in any compiler that actually implements the specification correctly.

(If you do things outside the specification, you're in undefined territory and there's no guarantee whatsoever about what will or won't happen.)

Historically, standards go back to things like screw threads, so that I can have some guarantee that if I order a screw of type X, it will fit in the hole I've drilled, and will be interchangeable with other screws of type X.

Which brings us back to the definition of the word "standard":

an accepted or approved example of something against which others are judged or measured — Collins Dictionary

An acknowledged measure of comparison for quantitative or qualitative value; a criterion. — The American Heritage® Stedman's Medical Dictionary

i.e. the thing you compare your stuff to to make sure you'll get what you expect.

  • 1
    There's also a standard for C#, .NET, the CLR, and C++/CLR published by ECMA, which was then fast-tracked to ISO. ISO also has a standard for HTML, ISO HTML 1.0 is a subset of W3C HTML 4.01 Strict. Sep 1, 2014 at 1:03

A technology standard is a specification such that two implementations of the same standard are expected to be interoperable or interchangeable. Examples: USB, Bluetooth, Java EE7, HTTP.

Then there are "de facto" standards: conventions that enable interoperability, but without an explicit agreed-upon specification. Example: The Microsoft DOC format has historically been a de facto standard, since many products could read and write DOC, but canonical specifications were not available (until much later). Documents were still commonly distributed in the DOC format, with the expectation that any receiver would be able to read it, thus it had become a de facto standard.

To address your specific example, REST doesn't have an explicit agreed-upon specification and is therefore not a true standard, and barely a de facto standard since it has considerable ambiguity in how it should be done correctly, and no dominant implementations exist that resolves these ambiguities. (I'm not against REST. It is a very good way to build web services)


A standard is a standardized convention - either by a formal specification, or simply because a common convention has gained enough popularity to be dominant.

A de jure standard is a specification published by a standard committee. Some standard committees are ISO, ECMA, DIN, ANSI, and W3C.

Some examples of de jure standards are the A4 paper size (ISO standard 219), the c# language (ECMA-334), etc.

The term 'de jure' is rarely used, and a 'de jure standard' is often just called a standard.

A de facto standard is a custom, convention, product, or system that has achieved a dominant position by public acceptance or market forces"

(source: wikipedia - I could't write it better myself)

A de facto standard does not necessarily follow any formal specification.

As Gudmundur Orn wrote in this answer, the Microsoft Office DOC format was a de facto standard. It had a dominant position, and it was normally assumed that people could read MS Word documents.

JSON is a funny beast, as it started out as a de facto standard. It has however since been formalized as ECMA-404, so it is now a 'de jure standard'.

It is however also the predominant format for exchanging data with HTTP-based APIs (to my knowledge), thus making it also the 'de facto standard' this purpose.


For legal product liability the defect are classed as design, manufacture or documentation. A design is not defective if it is based on a standard, whether or not that standard is defective. The standard that applies is that in place when the product was created. A standard may be a published standard (ISO) or an accepted industry standard that is not published by the standards association. So TCP/IP with all its inherent defects like spoofing is a standard and if you create a new technology like VOIP and don't do anything to protect the user from known problems with the underlying technology then you are safe to continue the mayhem. Or I may be wrong and have a documentation defect here...

  • 3
    By definition, a standard cannot be defective. However, a product implementing a standard correctly can be defective, it is just not fit for purpose. It doesn't matter how many or how well you follow standards, if the product doesn't satisfy the requirements of its intended purpose, it is defective.
    – Lie Ryan
    Sep 1, 2014 at 4:29

Not the answer you're looking for? Browse other questions tagged or ask your own question.