JSON and Rust: Why serde_json is the top choice

JSON has become one of the most common data exchange formats on the web, so it’s critical that server-side languages have good support for it. Fortunately, dealing with JSON is an area where Rust shines, thanks in large part to the serde and serde_json crates. These are among the most battle-tested crates in the Rust ecosystem and serve as great examples of ways to exploit Rust’s high-level abstractions while maintaining low-level control.

While there are plenty of other JSON crates available, serde_json is by far the most popular. The large ecosystem built around serde makes it the top choice for web servers written in Rust.

In this tutorial, we’ll explore serde_json and demonstrate how to use Rust’s type system to express JSON data.

Getting started

To get started with serde_json, you must first implement the Serialize and Deserialize traits on your types. Thanks to derive macros, this is really trivial for most types. To use derive macros, make sure you enable the “derive” feature flag for serde in your dependencies.

# cargo.toml

[dependencies]
serde = { version = "1", features = ["derive"] }
serde_json = "1"

Now we can use them like any other derive macro.

use serde::{Deserialize, Serialize};

#[derive(Debug, Deserialize, Serialize)]
struct Person {
    name: String,
    age: usize,
    verified: bool,
}

That’s all you need to do to make Person serializable and deserializable into any data format with a crate that supports serde. Debug is optional, but we’ll use it for demonstration purposes. Converting a JSON string into an instance of Person is now as simple as calling serde_json::from_str.

fn main() {
    let json = r#"
        {
          "name": "George",
          "age": 27,
          "verified": false
        }
    "#;

    let person: Person = serde_json::from_str(json).unwrap();

    println!("{:?}", person);
}

There are a couple of things to point out here, the first being the explicit Person type annotation. In this example, there is no way for the compiler to infer the type of person; it could potentially be any type that implements Deserialize. In more complete examples it would be inferred from things like function argument types when passing around person.

The other thing to note is the call to unwrap(). Deserialization can fail in a number of ways, so serde_json::from_str returns a Result to let us handle those failures. Errors from serde_json are quite rich and give us enough information to pin down exactly what went wrong. For example, running the same code as above with the age field removed triggers the following error message.

Error("missing field `age`", line: 5, column: 9)

You would get a similar message if there were syntax errors in the JSON. Instead of using unwrap, you can extract the same information seen above by using the methods provided by serde_json::Error and handle the error gracefully whenever possible.

One of my favorite things about using JSON in Rust is that it provides complete type checking with zero boilerplate code and error handling that is enforced at compile time thanks to the Result type. The places where you use JSON are almost always at system boundaries where you can receive all kinds of unexpected inputs. Having first-class, consistent support for error handling makes dealing with these system boundaries much more enjoyable and reliable.

Server example

So far, we’ve only scratched the surface of what serde and serde_json can do. To show them in action, we’ll create a server that calculates the perimeter and area of various shapes. We want requests to send JSON that look something like this:

{
  "calculation": "area",
  "shape": "circle",
  "radius": 4.5
}

As is often a good idea in Rust, we’ll start by thinking about types. The value of the calculation field in JSON is just a string. While we could use a Rust String, we need to enforce some invariants that aren’t captured by the String type. Instead of allowing any string value, we really just want to allow perimeter or area. A natural fit for something like this is an enum.

#[derive(Debug, Deserialize, Serialize)]
enum Calculation {
    Perimeter,
    Area,
}

JSON doesn’t include the concept of enums, but that’s OK because serde is flexible enough to massage these data types into a JSON equivalent. By default, the variants of Calculation will be converted to the JSON strings Perimeter and Area. That’s fine, but we’d prefer it if the strings were all lowercase. To accomplish that, we need to use our first serde attribute macro.

#[derive(Debug, Deserialize, Serialize)]
#[serde(rename_all = "lowercase")]
enum Calculation {
    Perimeter,
    Area,
}

As the name suggests, rename_all = "lowercase" will map the enum variants to lowercase strings in JSON.

The next fields in our desired JSON format are the shape name and the properties of that shape. These fields are tightly coupled to one another. A circle should have a radius, but a rectangle should not. To enforce this coupling in our types, we can use an enum with associated data.

#[derive(Debug, Deserialize, Serialize)]
enum Shape {
    Circle {
        radius: f64,
    },
    Rectangle {
        length: f64,
        width: f64,
    },
}

By default, this is represented by an externally tagged JSON object and adds nesting that we don’t want.

{
  "Circle": {
    "radius": 4.5
  }
}

We can fix this with another attribute.

#[derive(Debug, Deserialize, Serialize)]
#[serde(rename_all = "lowercase", tag = "shape")]
enum Shape {
    Circle {
        radius: f64,
    },
    Rectangle {
        length: f64,
        width: f64,
    },
}

The tag = "shape" attribute causes the JSON object to be internally tagged with a key of shape, giving the following.

{
  "shape": "circle",
  "radius": 4.5
}

Now we can create a Request type that puts a Calculation and a Shape together.

#[derive(Debug, Deserialize, Serialize)]
struct Request {
    calculation: Calculation,
    shape: Shape,
}

As you might have noticed, this type adds another layer of nesting that doesn’t match our desired JSON format.

{
  "calculation": "area",
  "shape": {
    "shape": "circle",
    "radius": 4.5
  }
}

Once again, we can solve this with an attribute.

#[derive(Debug, Deserialize, Serialize)]
struct Request {
    calculation: Calculation,
    #[serde(flatten)]
    shape: Shape,
}

This time, the flatten attribute is used to remove a layer of nesting. This can also often be useful in situations where you have a JSON object that contains some keys that don’t have a predictable name. To solve this, you can create a type where the known fields are mapped directly to a struct field and the unknown ones can be collected in a flattened HashMap.

You can now test what we have done so far in the same way we tested the Person type before.

fn main() {
    let json = r#"
        {
          "calculation": "perimeter",
          "shape": "circle",
          "radius": 2.3
        }
    "#;

    let request: Request = serde_json::from_str(json).unwrap();

    println!("{:?}", request);
}

I encourage you to play around with the input JSON to see how robust the type validation is and how helpful the errors are.

The final type we need for our application is a Response, which contains the result of the calculation.

#[derive(Debug, Deserialize, Serialize)]
struct Response {
    result: f64,
}

With all the types in place, we can build the logic that will actually perform the calculations.

use std::f64::consts::PI;

fn calculation_handler(request: Request) -> Response {
    let result = match (request.calculation, request.shape) {
        (Calculation::Perimeter, Shape::Circle { radius }) => PI * 2.0 * radius,
        (Calculation::Perimeter, Shape::Rectangle { length, width }) => 2.0 * length + 2.0 * width,
        (Calculation::Area, Shape::Circle { radius }) => PI * radius * radius,
        (Calculation::Area, Shape::Rectangle { length, width }) => length * width,
    };

    Response { result }
}

Since we’re enforcing invariants in the type system, our logic becomes simple and easy to reason about. In this case, it is a pure function that takes a Request and returns a Response, making it testable and completely decoupled from any web framework. One nice thing about serde is that it doesn’t force you to couple your logic and types to it since the derive macros don’t modify existing things; they purely add trait implementations.

As I mentioned earlier, serde_json can take advantage of the ecosystem around serde. Lots of crates contain code that is generic over types that implement the Serialize or Deserialize traits. A good example of this is web frameworks. Our handler already has a type signature that resembles a HTTP request-response cycle, so we will be able to plug it into any web framework that integrates with serde.

To build the web server, we need to add a couple of new dependencies.

[dependencies]
serde = { version = "1", features = ["derive"] }
tokio = { version = "0.2", features = ["macros"] }
warp = "0.2"

Next, replace the main function with an async function that sets up and starts the server.

use warp::Filter;

#[tokio::main]
async fn main() {
    let endpoint = warp::post()
        .and(warp::body::json())
        .map(|body| warp::reply::json(&calculation_handler(body)));
    warp::serve(endpoint).run(([127, 0, 0, 1], 5000)).await;
}

Don’t worry too much about what’s going on here; the important part is the closure inside of map. All we need to do for our logic to work with the warp web server is wrap the response in warp::reply::json. warp can do this by using serde_json under the hood.

At this point, we can try sending POST requests with a JSON body to localhost:5000 to test whether everything, including error messages, now works over our HTTP API.

Now you should have a decent grasp on how you can use Rust types to deal with JSON. One key takeaway from this example is that you can use Rust types that don’t have the exact structure of the JSON you interact with. When using more advanced features of Rust’s type system that more naturally fit the problem than a simple key-value object, we are free to use them without worrying about additional boilerplate.

The full code for this example is on GitHub.

Working without types

Although it is usually best to use your own types and derive the Serialize and Deserialize traits with serde_json, sometimes you either can’t or don’t want to. For those cases, you can work directly with the serde_json Value type. This is an enum that contains a variant for each possible data type in JSON.

// serde_json::Value

pub enum Value {
    Null,
    Bool(bool),
    Number(Number),
    String(String),
    Array(Vec<Value>),
    Object(Map<String, Value>),
}

An easy way create Values is with the serde_json::json macro. This essentially allows you to write JSON directly in Rust source code. If you have a Value representing an object or array, you can access the fields using Value::get, similar to Vec::get and HashMap::get.

use serde_json::json;

fn main() {
    let value = json!({
        "name": "Bob",
        "age": 51,
        "address": {
            "country": "Germany",
            "city": "Example City",
            "street": "Example Street"
        },
        "siblings": ["Alice", "Joe"]
    });

    println!(
        "{:?}",
        value.get("address").and_then(|name| name.get("country"))
    );
}

This example will print Some(String("Germany")). As you would expect, get returns an Option since the index or key might not exist.

That’s all there really is to using serde_json without custom types. As you might imagine this is useful for handling JSON with unknown keys and for quick prototypes. Since things like web frameworks are generic over the Serialize and Deserialize traits, which serde_json::Value implements, you can use these Values without any additional friction.

Conclusion

Being some of Rust’s most mature crates, serde and serde_json make working with JSON a breeze. In this guide, we went over how to use your own data types to represent known JSON structure and how to handle unknown JSON structures. Serde’s data model is extremely flexible, so you should be able to handle any JSON data with ergonomic, minimal boilerplate Rust.

To put it simply, JSON support shouldn’t be a concern for any Rust developer. It’s very much production-ready and arguably best in class compared to other mainstream languages.