serde-rs/json

Serde JSON  

Serde is a framework for serializing and deserializing Rust data structures efficiently and generically

Serde JSON  

Serde is a framework for serializing and deserializing Rust data structures efficiently and generically.


You may be looking for:

  • JSON API documentation
  • Serde API documentation
  • Detailed documentation about Serde
  • Setting up #[derive(Serialize, Deserialize)]
  • Release notes

JSON is a ubiquitous open-standard format that uses human-readable text to transmit data objects consisting of key-value pairs.

There are three common ways that you might find yourself needing to work with JSON data in Rust.

  • As text data. An unprocessed string of JSON data that you receive on an HTTP endpoint, read from a file, or prepare to send to a remote server.
  • As an untyped or loosely typed representation. Maybe you want to check that some JSON data is valid before passing it on, but without knowing the structure of what it contains. Or you want to do very basic manipulations like insert a key in a particular spot.
  • As a strongly typed Rust data structure. When you expect all or most of your data to conform to a particular structure and want to get real work done without JSON's loosey-goosey nature tripping you up.

Serde JSON provides efficient, flexible, safe ways of converting data between each of these representations.

Operating on untyped JSON values

Any valid JSON data can be manipulated in the following recursive enum representation. This data structure is serde_json::Value.

A string of JSON data can be parsed into a serde_json::Value by the serde_json::from_str function. There is also from_slice for parsing from a byte slice &[u8] and from_reader for parsing from any io::Read like a File or a TCP stream.

The result of square bracket indexing like v["name"] is a borrow of the data at that index, so the type is &Value. A JSON map can be indexed with string keys, while a JSON array can be indexed with integer keys. If the type of the data is not right for the type with which it is being indexed, or if a map does not contain the key being indexed, or if the index into a vector is out of bounds, the returned element is Value::Null.

When a Value is printed, it is printed as a JSON string. So in the code above, the output looks like Please call "John Doe" at the number "+44 1234567". The quotation marks appear because v["name"] is a &Value containing a JSON string and its JSON representation is "John Doe". Printing as a plain string without quotation marks involves converting from a JSON string to a Rust string with as_str() or avoiding the use of Value as described in the following section.

The Value representation is sufficient for very basic tasks but can be tedious to work with for anything more significant. Error handling is verbose to implement correctly, for example imagine trying to detect the presence of unrecognized fields in the input data. The compiler is powerless to help you when you make a mistake, for example imagine typoing v["name"] as v["nmae"] in one of the dozens of places it is used in your code.

Parsing JSON as strongly typed data structures

Serde provides a powerful way of mapping JSON data into Rust data structures largely automatically.

This is the same serde_json::from_str function as before, but this time we assign the return value to a variable of type Person so Serde will automatically interpret the input data as a Person and produce informative error messages if the layout does not conform to what a Person is expected to look like.

Any type that implements Serde's Deserialize trait can be deserialized this way. This includes built-in Rust standard library types like Vec<T> and HashMap<K, V>, as well as any structs or enums annotated with #[derive(Deserialize)].

Once we have p of type Person, our IDE and the Rust compiler can help us use it correctly like they do for any other Rust code. The IDE can autocomplete field names to prevent typos, which was impossible in the serde_json::Value representation. And the Rust compiler can check that when we write p.phones[0], then p.phones is guaranteed to be a Vec<String> so indexing into it makes sense and produces a String.

The necessary setup for using Serde's derive macros is explained on the Using derive page of the Serde site.

Constructing JSON values

Serde JSON provides a json! macro to build serde_json::Value objects with very natural JSON syntax.

The Value::to_string() function converts a serde_json::Value into a String of JSON text.

One neat thing about the json! macro is that variables and expressions can be interpolated directly into the JSON value as you are building it. Serde will check at compile time that the value you are interpolating is able to be represented as JSON.

This is amazingly convenient but we have the problem we had before with Value which is that the IDE and Rust compiler cannot help us if we get it wrong. Serde JSON provides a better way of serializing strongly-typed data structures into JSON text.

Creating JSON by serializing data structures

A data structure can be converted to a JSON string by serde_json::to_string. There is also serde_json::to_vec which serializes to a Vec<u8> and serde_json::to_writer which serializes to any io::Write such as a File or a TCP stream.

Any type that implements Serde's Serialize trait can be serialized this way. This includes built-in Rust standard library types like Vec<T> and HashMap<K, V>, as well as any structs or enums annotated with #[derive(Serialize)].

Performance

It is fast. You should expect in the ballpark of 500 to 1000 megabytes per second deserialization and 600 to 900 megabytes per second serialization, depending on the characteristics of your data. This is competitive with the fastest C and C++ JSON libraries or even 30% faster for many use cases. Benchmarks live in the serde-rs/json-benchmark repo.

Getting help

Serde is one of the most widely used Rust libraries so any place that Rustaceans congregate will be able to help you out. For chat, consider trying the #general or #beginners channels of the unofficial community Discord, the #rust-usage channel of the official Rust Project Discord, or the #general stream in Zulip. For asynchronous, consider the [rust] tag on StackOverflow, the /r/rust subreddit which has a pinned weekly easy questions post, or the Rust Discourse forum. It's acceptable to file a support issue in this repo but they tend not to get as many eyes as any of the above and may get closed without a response after some time.

No-std support

As long as there is a memory allocator, it is possible to use serde_json without the rest of the Rust standard library. This is supported on Rust 1.36+. Disable the default "std" feature and enable the "alloc" feature:

For JSON support in Serde without a memory allocator, please see the serde-json-core crate.


License

Licensed under either of Apache License, Version 2.0 or MIT license at your option.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in this crate by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.
Issues

Collection of the latest Issues

lucacasonato

lucacasonato

Comment Icon0

Usually serde_json can deserialize JSON strings into byte buffers, which makes deserializing JSON with lone surrogate pairs (which are valid JSON), possible (see #828).

Unfortunately, this is not possible when serde_json is driving the deserialization visitor, i.e. with deserialize_any. To my knowledge this makes it impossible to deserialize unknown JSON values while not erroring on lone surrogates using serde_json.

I understand this is rather contrived, but it'd be great to figure out a solution to this. I am not really sure how though. My best idea is to add a way for visitors to tell the Deserializer what visitation types it supports/prefers, so the Deserializer can make informed decisions about how to handle data types that can be deserialized in multiple ways in deserialize_any. This could look something like this:

This would require a change to serde though, which may not be desirable or possible.

I'd love to hear feedback on this.

tbu-

tbu-

Comment Icon0

It seems that if any struct field in the path to a Box<RawValue> is marked with #[serde(flatten)], deserialization always fails.

In the example below, Def can deserialize a certain JSON string, but the struct Abc containing a single #[serde(flatten)] Def field fails.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a7a182c5711834ea12a847374eb08de5

Might have a similar root cause as #497, #545, #599 or #779.

Randall-Coding

Randall-Coding

Comment Icon3

I have some json incoming from a 3rd party api that looks like this:

which may change. For example that v2 might become v3, while still being nested in the same location. All I care about is accessing "entries" items so is there a way I could do that by traversing the tree perhaps using pointers? Or some other method of traversing, such that I could say "select first item, select next nested item, select next nested item" without using the key name directly?

So for example I'd have the above Value stored in json_res and I'd want to call something like json_res.child(1).child(1).child(1).

Or better yet is there some traversing function that I could call such as json_res.get_first("entries") which traverses the tree until it finds the first instance of that key value.

Carter12s

Carter12s

Comment Icon0

I'm working on a command line utility that takes json data payloads as an argument.

An incredibly convenient feature of this utility is to generate a "stub" json of the correct structure for the user to then fill with valid data.

Example:

I've achieved this functionality so far by requiring all structs that interact with this CLI to impl Default and passing their default value into serde_json to generate the stub.

I'm curious about the following:

  1. serde_json should technically be able to generate these stubs without requiring a default I think?
  2. If this is technically possible, would it be an worthwhile API to add to serde_json, and if I created an MR would it be accepted?
bitdivine

bitdivine

Comment Icon0

It would be useful to be able to update just some parts of a structure. Example:

If I have:

I should be able to update an existing point without having to specify all the fields:

There is an existing serde method that deserializes into an existing struct, but in serde_json it aborts with an error if there are missing fields. If it could be told to ignore missing fields and just carry on, it seems as if maybe this could be achieved fairly easily. Here is a playground that demonstrates this: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=bccf10311e413af139f3fee957a1e747

I am aware that there are full-blown json-patch implementations. One could convert an existing strict into JSON, apply a patch and concert back. That is quite heavyweight, where the usual point of deserializing into an existing struct is speed and low memory footprint. Also, I don't believe that JSON patch really belongs in serde; it is an operation on JSON that can live entirely outside serde. The same does not apply here, unless one goes with the inefficient "convert everything to JSON, merge, convert back" approach.

Are there people who would support such an "ignore missing, use existing value" update?

nanoqsh

nanoqsh

Comment Icon1

I write a deserialization using the from or try_from attribute because it saves a lot of code lines compared to manual implementation. Often deserialization comes from strings. Therefore, I implement the (Try)From<&str> trait for my type, since it is more general and doesn't require any allocation. Here is an simplified example:

But when I want to test deserialization, for example in unit tests using json! macro, it doesn't work. The serde_json::from_value function gives an error, although other methods work fine:

Playground

This behavior is highly unobvious and confusing. It's not clear why in one case everything is fine, and in the other it's not. Although, if you write the implementation manually, it also works fine:

Playground

Is it possible to fix this behavior?

djc

djc

Comment Icon0

If I'm not mistaken, JSON output will always be UTF-8. However, as far as I know from the API, the to_string{,_pretty}() and to_vec{,_pretty}() functions allocate a new string buffer and the to_writer{,_pretty}() variants write into an abstraction based on bytes; that is, the invariant that the output JSON is UTF-8 must be enforced/clarified by the caller.

It would be nice if there was a way to write into a &mut String and/or a &mut std::fmt::Formatter<'_>.

scrblue

scrblue

Comment Icon2

As per the comment for deserialize_bytes, it is expected that you can deserialize a non-UTF-8 string into a ByteBuf without failure. However, with flattened structures, deserialize_map is called in place of deserialize_struct (see https://github.com/serde-rs/serde/issues/1529), meaning members are deserialized with deserialize_any bypassing deserialize_bytes. deserialize_any assumes values surrounded by quotation marks are valid UTF-8 strings and returns an error otherwise.

An example follows

tustvold

tustvold

Comment Icon0

Currently by default this crate supports numbers up to 64-bits. For larger types it is necessary to enable the arbitrary_precision feature, which treats numbers as strings. Whilst this works, it can have unintended consequences as it changes the semantics of how integers are fed into the serde machinery - see #845.

I wonder if serde_json might add support for 128-bit types within Number and the associated serializer implementations on platforms that support such types - e.g. by using serde_if_integer128. This would allow crates to use 128-bit types without needing to opt-in to arbitrary_precision.

I would be happy to contribute a PR if this is an acceptable course of action?

hniksic

hniksic

Comment Icon0

Is there a convenience method to convert owned value to owned String, like an owned version of as_str(). For example:

The above doesn't compile, and there is no Value::into_string() or similar. As far as I can tell, the only way to extract the string is by matching:

I need this kind of thing fairly often and I wonder if there's a more succinct way to write the above. Of course, I can write a utility function that does it, but would prefer to use a standard API offered by the crate if possible.

piegamesde

piegamesde

Comment Icon0

I notice that the Map struct is generic over a K and V type parameter. However, these are completely useless as far as I can tell: All implementations for Map are for Map<String, Value>. Thus, when using the struct, I always have to write those type parameters, which is annoying since they will always be the same.

Is there maybe a way to add default types to the parameters to make it less verbose? (A type alias might work fine as well though.)

Stargateur

Stargateur

Comment Icon0

Value have several help method like as_* combine with take() this allow fast and dirty code. But there is no more direct way cause as_* take Value as &Self.

Example:

fenhl

fenhl

docs
Comment Icon1

There are some cargo features that appear to modify the behavior of the crate, but it is not clear what exactly they do. It would be useful to have an overview of the following features in the crate-level docs:

  • preserve_order
  • raw_value
  • unbounded_depth
  • arbitrary_precision
  • float_roundtrip
rw

rw

support
Comment Icon1

Is it possible to leave all strings escaped? For example, in a Visitor, I would like the following JSON to invoke the following Visitor calls:

instead of these visitor calls:

Thanks!

jplatte

jplatte

Comment Icon0

I find myself writing

again and again. Would you accept a PR that adds a type alias like that (without the Json prefix) to serde_json::value, uses it for the Value::Object variant and maybe re-exports it at the crate root too?

Alexhuszagh

Alexhuszagh

Comment Icon1

There have been a few updates to the moderate path float parsing algorithms in minimal-lexical, which can either provide performance benefits or reduce the amount of static storage required, depending on your use-case. I'll summarize a list of plausible options below, and if any seem beneficial to the maintainers of serde-json, will be happy to submit a PR.

Quick Background

Just for a quick summary: the float parsing algorithm is broken into 3 parts:

  • A fast path algorithm, where the significant digits can be exactly represented as a native float without truncated.
  • A moderate path algorithm, to process all floats except near-halfway cases through an extended representation of a float.
  • A slow path algorithm, that discerns the proper way to round near-halfway floats using arbitrary-precision arithmetic.

The moderate path is ~66-75% faster than the slow path, and therefore improvements to it either from a performance standpoint or correctness standpoint can lead to dramatic performance gains.

Interpolate the Cached Power Exponent

Serde uses pre-computed values for the cached float exponents in cached_float80. However, we can interpolate all these exponents, since each exponent is just effectively ⌈ log2(10) * exp10 ⌉. Using a pre-computed, integral power for log2(10), we can calculate the exponent exactly from the index to the cached power.

The specific pseudo-code can be used to generate this magic number, and verify it produces the correct result over the entire range of valid exponents:

See the appendix to see the full changes required to implement this change.

Pros:

  • Less storage required.
  • No discernible impact on runtime performance.

Cons:

  • N/A

Correctness Concerns:

  • N/A, can be proven the generated exponents are identical for all valid inputs.

Add the Eisel-Lemire Algorithm.

A fast algorithm for creating correct representations of floats from an extended 128-bit (or 192-bit) representation was developed and is currently in use in major Google projects like Golang and Wuffs, as well as others. The Eisel-Lemire algorithm is ~15% for a uniform distribution of randomly-generated floats over the entire float range, and catches halfway cases different than the existing extended-float algorithm.

A few examples of cases:

  • "9007199254740992.0" (or 1<<53): correctly classified by both.
  • "9007199254740992000.0e-3"(or 1<<53): only classified by extended-float only.
  • "9007199254740993.0" (or 1 + (1<<53`): both cannot classify.
  • "9007199254740994.0" (or 2 + (1<<53)`): correctly classified by both.
  • "9007199254740995.0" (or 3 + (1<<53)`): correctly classified by Eisel-Lemire only.
  • "9007199254740996.0" (or 4 + (1<<53)`): correctly classified by both.
  • "2.470328229206232720e-324" (near-halfway subnormal float): correctly classified by extended-float only.
  • "8.988465674311580536e307" (large near-halfway float): correctly classified by Eisel-Lemire only.

In short, the two combined have overlapping coverage, and can avoid delegating to the slow path algorithm, leading to major performance benefits. See minimal-lexical/lemire.rs for an example implementation of this algorithm. The general approach therefore is run Eisel-Lemire, and if the algorithm fails, delegate to the extended-float algorithm.

Pros:

  • Slightly faster performance than extended-float in some cases.
  • Can be combined with extended-float to minimize delegating to the slow path.
  • Can use pre-computed powers for Eisel-Lemire for extended-float too, leading to minor performance improvements.

Cons:

  • Increased storage required (requires an additional 1226 u64s, or ~9.8 KB).

Correctness Concerns:

  • Substantial, but well-established algorithm and passes all correctness tests.
  • It passes the curated suite of halfway cases, a large, curated suite of cases used to validate Go's parser, and Rust's extensive randomly-generated test-cases.

Replace Extended-Float with Lemire

A third option is to entirely remove the extended-float algorithm, and replace it with the Eisel-Lemire algorithm. In order to do so, we need to round-down to b so the slow algorithm can correctly differentiate between b, b+h, and b+u. Extensive comments and code samples are included in lexical-core/lemire.rs for how to implement this.

Pros:

  • Slightly faster performance than extended-float in some cases.

Cons:

  • Increased storage required (requires an additional 1226 u64s, or ~9.8 KB).
  • Less correct than extended-float, and therefore delegates to the slow path algorithm more often.

Correctness Concerns:

  • Substantial, but well-established algorithm and passes all correctness tests.
  • It passes the curated suite of halfway cases, a large, curated suite of cases used to validate Go's parser, and Rust's extensive randomly-generated test-cases.

Appendix

Interpolation

The full changes to interpolate the exponent are the following:

Versions

Find the latest versions by id

v1.0.81 - May 03, 2022

  • Work around indexmap/autocfg not always properly detecting whether a std sysroot crate is available (#885, thanks @cuviper)

v1.0.80 - May 03, 2022

  • Documentation improvements

v1.0.79 - Feb 12, 2022

  • Allow RawValue deserialization to propagate \u escapes for unmatched surrogates, which can later by deserialized to Vec<u8> (#830, thanks @lucacasonato)

v1.0.78 - Jan 22, 2022

  • Support deserializing as &RawValue in map key position, which would previously fail with "invalid type: newtype struct" (#851)

v1.0.77 - Jan 22, 2022

  • Include discord invite links in the published readme
  • Improve compile error on compiling with neither std nor alloc feature enabled
  • Include integration tests in published package (#578)

v1.0.76 - Jan 22, 2022

  • Fix a build error when features raw_value and alloc are enabled while std is disabled (#850)

v1.0.75 - Jan 22, 2022

  • Fix deserialization of small integers in arbitrary_precision mode (#845)

v1.0.74 - Jan 01, 2022

  • Allow creating RawValues from references to unsized values (#841, thanks @EFanZh)

v1.0.73 - Dec 13, 2021

  • Update itoa dependency to 1.0

v1.0.72 - Nov 25, 2021

  • Interpret \u-encoded lone surrogates when deserializing into a byte string (#828, #829, thanks @lucacasonato)

v1.0.71 - Nov 17, 2021

  • Add serde_json::Map::get_key_value (#821, thanks @timothee-haudebourg)
  • Add impl From<Box<RawValue>> for Box<str> (#824, thanks @jplatte)

v1.0.70 - Nov 13, 2021

  • Add serde_json::Map::retain method (#822, thanks @deankarn)

v1.0.69 - Nov 05, 2021

  • Implement Hash for serde_json::Number (#814, thanks @timothee-haudebourg)

v1.0.68 - Sep 14, 2021

  • Preserve negative sign of -0 when deserializing to f32 or f64 (#799, #801)

v1.0.67 - Aug 28, 2021

  • Fix inconsistency of deserialization of unknown fields in a struct variant from bytes vs from Value (#795)

v1.0.66 - Jul 29, 2021

  • Preserve exponent signifier and unary plus in exponent of arbitrary_precision numbers (#786, thanks @ruifengx)

v1.0.65 - Jul 28, 2021

  • Documentation improvements

v1.0.64 - Feb 28, 2021

  • Fix deserialization panic on deserializing RawValue from a slice containing non-utf8 bytes (#755)

v1.0.63 - Feb 25, 2021

v1.0.62 - Feb 05, 2021

  • Speed up Display impl of serde_json::Value by 33% (#751, thanks @icewind1991)

v1.0.61 - Dec 28, 2020

  • Add impl From<Number> for Value (#737, thanks @imp)

v1.0.60 - Dec 02, 2020

  • Add impl FromIterator<(impl Into<String>, impl Into<Value>)> for Value, which collects a Value::Object (#733, thanks @matklad)

v1.0.59 - Dec 02, 2020

  • In arbitrary_precision mode, return None from serde_json::Number::as_f64 if the JSON number is larger than the maximum possible f64

v1.0.58 - Sep 30, 2020

  • Add serde_json::Map::remove_entry, matching the equivalent API on BTreeMap

v1.0.57 - Jul 26, 2020

  • Allow serde_json::Deserializer to be instantiated without consuming the serde_json::​de::Read impl (#684)

v1.0.56 - Jun 29, 2020

v1.0.55 - Jun 10, 2020

v1.0.54 - Jun 09, 2020

  • Add float_roundtrip feature to enable a slower but higher precision float parser based on lexical.

    Enabling float_roundtrip will use sufficient precision when parsing fixed precision floats from JSON to ensure that they maintain accuracy when round-tripped through JSON. This comes at an approximately 2x performance cost for parsing floats compared to the default best-effort precision.

    Unlike arbitrary_precision, the new float_roundtrip feature makes f64 -> JSON -> f64 produce output identical to the input. arbitrary_precision is for making JSON -> serde_json::Number -> JSON produce output identical to the input.

v1.0.53 - May 10, 2020

  • Reduce unhelpful indentation in the {:#?} format of serde_json::Value
  • Remove some unnecessary runtime checks from Serializer::collect_str

v1.0.52 - Apr 28, 2020

Information - Updated Jun 02, 2022

Stars: 3.0K
Forks: 404
Issues: 94

Repositories & Extras

Serde is a framework for serializing and deserializing Rust data structures efficiently and generically

Rust Greatest JSON weapon is Serde with over 4.4K stars on github and a massive developer community. This is considered a core Rust library for every developer to learn in BRC's opinion

Serde is a framework for serializing and deserializing Rust data structures efficiently and generically

Rust 버전 JsonPath 구현으로 Webassembly와 Javascript에서도 유사한 API 인터페이스를 제공 한다

JsonPath 구현으로 Webassembly와 Javascript에서도 유사한 API 인터페이스를 제공 한다

Rust 버전 JsonPath 구현으로 Webassembly와 Javascript에서도 유사한 API 인터페이스를 제공 한다

SIMD JSON for Rust  

Rust port of extremely fast serde compatibility

SIMD JSON for Rust  

JSON-E Rust data-struct paramter crate for lightweight embedded content with objects and much more

What makes JSON-e unique is that it extensive documentation and ease of use

JSON-E Rust data-struct paramter crate for lightweight embedded content with objects and much more
JSON

111

A Rust JSON5 serializer and deserializer which speaks Serde

Deserialize a JSON5 string with from_str

A Rust JSON5 serializer and deserializer which speaks Serde

Rust JSON Parser Benchmark

Download and Generate JSON Data

Rust JSON Parser Benchmark

Read JSON values quickly - Rust JSON Parser

AJSON get json value with specified path, such as project

Read JSON values quickly - Rust JSON Parser

Rust actix json request example

Send a json request to actix, and parse it

Rust actix json request example
JSON

140

json_typegen - Rust types from JSON samples

json_typegen is a collection of tools for generating types from

json_typegen - Rust types from JSON samples

Rust JSON parsing benchmarks

This project aims to provide benchmarks to show how various JSON-parsing libraries in the Rust programming language perform at various JSON-parsing tasks

Rust JSON parsing benchmarks

A tiny command line tool written in rust to print json data as a formatted...

A tiny command line tool written in rust to print json data as a formatted table

A tiny command line tool written in rust to print json data as a formatted...

Rust RPC client for Bitcoin Core JSON-RPC

rust-jsonrpc and makes it easier to talk to the Bitcoin JSON-RPC interface

Rust RPC client for Bitcoin Core JSON-RPC
Facebook Instagram Twitter GitHub Dribbble
Privacy