What follows is an infinite array (so it should be parsed by a streaming JSON parser, but as described above you can go for a simpler solution), whose elements are one array per status line.

'Content-Type' HTTP response header value MUST be :

Content-Type: text/json

Noggit supports a number of extensions to the JSON grammar. All of these extensions are optional and may be disabled.

Comments

{ // This is a single line comment

  # This is also a single line comment

  /* This is a multi-line

   * C-style comment.

   */

}

Unquoted Strings

{

  first : Yonik,

  last : Seeley

}

Single Quoted Strings

JSON strings are normally encapsulated by double quotes. It’s often desirable to use single quotes if for example you are embedding some JSON in another double quoted string in a program.

['how', 'now', 'brown', 'cow']

Backslash escape any character

Sometimes one may not know exactly what characters need to be backslash escaped. It can be useful to accept this without throwing an exception.

'This is just a " string'

Trailing commas / extra commas

Although flow outputs standard JSON, quotes and curly braces are omitted in the sample JSON listings in this document to make them easier to read. We call this light JSON format "JSON-L".

The JSON working group will have as its only task the minor

revision of RFC 7159 to bring it to Internet Standard, and fully

acknowledge the syntax definition in ECMA-404. The work is essentially

a reclassification in place, with absolute minimal changes, though those

changes will require publication of a new RFC.

The WG charter is at < https://datatracker.ietf.org/wg/jsonbis/charter/ >.

In a nutshell, the goal of this effort is to produce a bis to 7159 that:

* promotes JSON to IETF Internet Standard

* references ECMA-404 and is a reference for ECMA-404

Tim Bray has agreed to edit 7159bis.

As a start, I propose we start with rfc7159 and:

1) Apply verified errata from < https://www.rfc-editor.org/errata_search.php?rfc=7159 >

2) Change the reference to ECMA-404 from informative to normative

I have really major heartburn with introducing a Normative Reference to ECMA404 in 7159bis.  Because language in standards documents should be used carefully, and “Normative Reference” has a very specific meaning, and that meaning clearly does not apply in this case.  However, since there is apparently a feeling that there is some benefit to the community in achieving “standards harmony”, let me propose three ways forward:

1. Include a normative reference to ECMA404, but accompany it with text explaining that this reference is marked normative because it is considered authoritative in the community of _javascript_ language specifiers, not in the normal sense of “normative”; there is no necessity to read it in order too understand or implement RFC7159bis, nor does it specify any technology which must be present in an implementation that is not also described in 7159bis.”

2. Do not include a normative reference, but expand the note about ECMA404 in Section 1.2 to emphasize that ECMA404 may be considered authoritative in the community of _javascript_ implementers.

3. Conclude that this effort has no observable benefit to the community implementing JSON on the Internet and abandon the RFC7159bis project.

To request this format using $format, use the value jsonverbose. To request this format using the Accept header, use the MIME type application/json;odata=verbose.

curlの場合

curl -i -H "Accept: application/json; version=0.5" -X GET http://localhost:8080/api/users

今回はversion<1.0.0だとerrorを返すようにしました。

Some examples use the combination of a JavaScript single-line comment

(//) followed by an ellipsis (...) as placeholder notation for

content deemed irrelevant by the authors. These placeholders must of

course be deleted or otherwise replaced, before attempting to

validate the corresponding JSON code example.

The only variation now compared to ES6 JSON.stringify is that

Go continues to encode negative zero as "-0", not "0", so that

the value continues to be preserved during JSON round trips.

I just noticed that the document went to state "Publication Requested" early December, with no notification of the working group, and (IMHO) some of the few feedback that the document received during WG LC being ignored

The input may contain deviations from the grammar of [RFC 7159], which are handled in an ·implementation-defined· way. (Note: some popular extensions include allowing quotes on keys to be omitted, allowing a comma to appear after the last item in an array, allowing leading zeroes in numbers, and allowing control characters such as tab and newline to be present in unescaped form.) Since the extensions accepted are implementation-defined, an error may be raised [err:FOJS0001] if the input does not conform to the grammar.

reject An error is raised [err:FOJS0003] if duplicate keys are encountered.

use-first If duplicate keys are present in a JSON object, all but the first of a set of duplicates are ignored.

use-last If duplicate keys are present in a JSON object, all but the last of a set of duplicates are ignored.

Content-Type: application/json; profile="http://example.com/alpha"

The conversion only takes place if the "/" characters are escaped (that is, the JSON looks like "\/Date(700000+0500)\/"), and for this reason WCF's JSON encoder (enabled by the WebHttpBinding) always escapes the "/" character.

If you specify no accept header, we’ll return human-readable JSON with comments. If you prefer to receive compact JSON with no whitespace or comments, add the "application/json" Accept header.

RFC7159 is taken as the definitive specification of JSON for the purposes of this document. The RFC explains its relationship with other JSON specifications such as [ECMA-404].

Many JSON implementations allow commas to be used after the last item in an object or array, although the specification does not permit it. The option spec="liberal" is provided to allow such deviations from the specification to be accepted. Some JSON implementations also allow constructors such as new Date("2000-12-13") to appear as values: specifying spec="liberal" allows such extensions to be accepted, but does not guarantee it.

SafariDriverサーバーの スクリーンショットを取得するWebDriver API で返ってくるBASE64データが、ChromeDriverサーバーやGeckoDriverサーバーなどと違って、スラッシュ記号がエスケープされた状態になっています。これはJSON仕様としては正しい(エスケープしてもしなくてもいい)実装で、公式クライアントライブラリーもこれに対応して正しくスクリーンショットのデータを取得できる状態になっています。

2nd edition (December 2017)

Requests and responses with a JSON message body MUST have a Content-Type header value of application/json.

Requests MAY add the charset parameter to the content type. Allowed values are UTF-8, UTF-16, and UTF-32. If no charset parameter is present, UTF-8 MUST be assumed.

Responses MUST include the metadata parameter to specify the amount of metadata included in the response.

Responses MUST include the IEEE754Compatible parameter if Edm.Int64 and Edm.Decimal numbers are represented as strings.

Requests and responses MAY add the streaming parameter with a value of true or false, see section Payload Ordering Constraints.