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.
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.
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.
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 Value
s 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 Value
s without any additional friction.
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.
Debugging Rust applications can be difficult, especially when users experience issues that are hard to reproduce. If you’re interested in monitoring and tracking the performance of your Rust apps, automatically surfacing errors, and tracking slow network requests and load time, try LogRocket.
LogRocket is like a DVR for web and mobile apps, recording literally everything that happens on your Rust application. Instead of guessing why problems happen, you can aggregate and report on what state your application was in when an issue occurred. LogRocket also monitors your app’s performance, reporting metrics like client CPU load, client memory usage, and more.
Modernize how you debug your Rust apps — start monitoring for free.
Hey there, want to help make our blog better?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up nowSimplify component interaction and dynamic theming in Vue 3 with defineExpose and for better control and flexibility.
Explore how to integrate TypeScript into a Node.js and Express application, leveraging ts-node, nodemon, and TypeScript path aliases.
es-toolkit is a lightweight, efficient JavaScript utility library, ideal as a modern Lodash alternative for smaller bundles.
The use cases for the ResizeObserver API may not be immediately obvious, so let’s take a look at a few practical examples.