Deriving `Serialize` and `Deserialize`

19 min read

In TypeScript, any object is serializable to JSON for free — JSON.stringify walks its enumerable properties at runtime. Rust has no runtime reflection, so a type can only be serialized if it explicitly implements the Serialize trait (and deserialized only if it implements Deserialize). The #[derive(Serialize, Deserialize)] attribute makes the Serde derive macro write those implementations for you at compile time, so your structs and enums round-trip to JSON, TOML, YAML, and dozens of other formats with one line.

Quick Overview

What it is: A derive macro from the serde crate that generates Serialize and/or Deserialize trait implementations for your structs and enums.
Why it matters: It is the Rust equivalent of “this object is JSON-ready.” Without it, serde_json::to_string(&value) will not even compile, because the compiler cannot find a Serialize impl for your type.
The mental shift: Unlike JSON.stringify, which works on any value at runtime, Rust decides at compile time exactly which types can be serialized. The derive macro is how you opt a type in.

Note: This page focuses on the derive macro itself — where you put it, what it generates, and how it behaves on every kind of struct and enum. Setting up the dependency is covered in serde-basics.md, the trait architecture in serde-intro.md, and the many #[serde(...)] field attributes in attributes.md.

TypeScript/JavaScript Example

In TypeScript you never declare a type serializable. Every plain object is fair game for JSON.stringify, and JSON.parse hands you back an untyped any that you assert into a shape:

1
// TypeScript - serialization is implicit and works on any object
2
interface User {
3
  id: number;
4
  username: string;
5
  email: string;
6
  isActive: boolean;
7
}
8

9
const user: User = {
10
  id: 42,
11
  username: "ada",
12
  email: "ada@example.com",
13
  isActive: true,
14
};
15

16
// Object -> JSON string. No declaration needed; structural and runtime-driven.
17
const json = JSON.stringify(user);
18
console.log(json);
19
// {"id":42,"username":"ada","email":"ada@example.com","isActive":true}
20

21
// JSON string -> object. The cast is a lie the compiler trusts blindly.
22
const parsed = JSON.parse(json) as User;
23
console.log(parsed.username); // "ada"

There are two hidden costs that Rust will make explicit:

1
// 1. Methods and prototype are silently dropped — only data survives.
2
class Account {
3
  constructor(public id: number, public name: string) {}
4
  greet() {
5
    return `Hi ${this.name}`;
6
  }
7
}
8

9
const acct = new Account(7, "Grace");
10
const restored = JSON.parse(JSON.stringify(acct));
11
console.log(restored instanceof Account); // false
12
console.log(typeof restored.greet); // "undefined"
13

14
// 2. `as User` is unchecked. If the JSON is missing `email`, you get
15
//    `undefined` at runtime with zero warning at the boundary.

Rust Equivalent

In Rust you annotate the type once. The derive macro generates the trait implementations the serializer needs:

1
// Cargo.toml:
2
//   [dependencies]
3
//   serde = { version = "1", features = ["derive"] }
4
//   serde_json = "1"
5
use serde::{Deserialize, Serialize};
6

7
#[derive(Debug, Serialize, Deserialize)]
8
struct User {
9
    id: u64,
10
    username: String,
11
    email: String,
12
    is_active: bool,
13
}
14

15
fn main() {
16
    let user = User {
17
        id: 42,
18
        username: String::from("ada"),
19
        email: String::from("ada@example.com"),
20
        is_active: true,
21
    };
22

23
    // Struct -> JSON string (serialize).
24
    let json = serde_json::to_string(&user).unwrap();
25
    println!("{json}");
26

27
    // Pretty-printed JSON.
28
    let pretty = serde_json::to_string_pretty(&user).unwrap();
29
    println!("{pretty}");
30

31
    // JSON string -> struct (deserialize). The type annotation tells Serde
32
    // exactly which shape to build, and it is *checked*.
33
    let parsed: User = serde_json::from_str(&json).unwrap();
34
    println!("{parsed:?}");
35
}

Real output:

1
{"id":42,"username":"ada","email":"ada@example.com","is_active":true}
2
{
3
  "id": 42,
4
  "username": "ada",
5
  "email": "ada@example.com",
6
  "is_active": true
7
}
8
User { id: 42, username: "ada", email: "ada@example.com", is_active: true }

The single #[derive(Serialize, Deserialize)] line replaces both JSON.stringify capability and the unchecked as User cast — and unlike the cast, deserialization actually validates that every required field is present and correctly typed.

Detailed Explanation

What `derive` is, and why it is needed

Serialize and Deserialize are traits (Rust’s version of interfaces — see section 09). A function like serde_json::to_string is generic over T: Serialize, so you can only pass it a value whose type implements Serialize. Rust has no runtime reflection, so there is no way to “just walk the fields” the way JSON.stringify does. Someone has to write the field-by-field code — and #[derive(...)] is that someone.

#[derive(Trait)] runs a procedural macro at compile time that reads your type’s definition and emits an impl Trait for YourType { ... } block. (Macros are covered in depth in section 14.) It is not a runtime annotation or decorator; by the time your program runs, the generated code is indistinguishable from code you typed by hand.

What the derive actually generates

For a struct, the generated Serialize impl visits each field in declaration order. You rarely look at it, but it helps to see that it is plain, ordinary Rust. Here is a hand-written Serialize that is effectively what the derive produces:

1
use serde::ser::{Serialize, SerializeStruct, Serializer};
2

3
struct User {
4
    id: u64,
5
    username: String,
6
    is_active: bool,
7
}
8

9
// This is roughly what `#[derive(Serialize)]` writes for you.
10
impl Serialize for User {
11
    fn serialize<S>(&self, serializer: S) -> Result<S::Ok, S::Error>
12
    where
13
        S: Serializer,
14
    {
15
        // Announce "I am a struct named User with 3 fields".
16
        let mut state = serializer.serialize_struct("User", 3)?;
17
        state.serialize_field("id", &self.id)?;
18
        state.serialize_field("username", &self.username)?;
19
        state.serialize_field("is_active", &self.is_active)?;
20
        state.end()
21
    }
22
}
23

24
fn main() {
25
    let user = User { id: 42, username: "ada".into(), is_active: true };
26
    println!("{}", serde_json::to_string(&user).unwrap());
27
    // {"id":42,"username":"ada","is_active":true}
28
}

Real output:

1
{"id":42,"username":"ada","is_active":true}

Two things to notice:

The impl is format-agnostic. It talks to an abstract Serializer (serialize_struct, serialize_field), not to JSON specifically. That is why the same derived type can also produce TOML or MessagePack — see other-formats.md.
It is recursive by composition. serialize_field("id", &self.id) only works because u64 itself implements Serialize. Serde ships impls for all the standard types (String, Vec<T>, Option<T>, HashMap<K, V>, etc.), and your derived impl reuses them.

Deserialize is generated the same way but is considerably more code — it builds a “visitor” state machine that can accept fields in any order, report missing fields, and ignore unknown ones. It is verbose enough that you almost never want to write it by hand; that is the whole point of the derive. (custom-serialization.md covers the rare cases where you do.)

`Serialize` and `Deserialize` are independent

They are two separate traits, and you derive only what you need:

#[derive(Serialize)] — the type can be turned into a format (write-only). Common for response/output types.
#[derive(Deserialize)] — the type can be built from a format (read-only). Common for request/config types.
#[derive(Serialize, Deserialize)] — both directions, for types that round-trip.

This is finer-grained than TypeScript, where every shape is implicitly both directions.

Every field’s type must also implement the trait

This is the rule that trips up everyone coming from TypeScript. Because the generated code calls serialize_field("address", &self.address), the type of address must itself implement Serialize. There is no “deep stringify everything” fallback. If a nested type lacks the derive, your code will not compile (see Common Pitfalls).

It works on enums too

Enums are where Serde shines compared to TypeScript’s hand-rolled discriminated unions. Each variant kind serializes to a distinct, predictable JSON shape:

1
use serde::{Deserialize, Serialize};
2

3
#[derive(Debug, Serialize, Deserialize)]
4
enum Event {
5
    // Unit variant: no data.
6
    Logout,
7
    // Newtype variant: one unnamed field.
8
    PageView(String),
9
    // Tuple variant: multiple unnamed fields.
10
    Click(u32, u32),
11
    // Struct variant: named fields.
12
    Purchase { item_id: u64, quantity: u32 },
13
}
14

15
fn main() {
16
    let events = vec![
17
        Event::Logout,
18
        Event::PageView(String::from("/home")),
19
        Event::Click(120, 45),
20
        Event::Purchase { item_id: 7, quantity: 2 },
21
    ];
22

23
    for event in &events {
24
        println!("{}", serde_json::to_string(event).unwrap());
25
    }
26
}

Real output:

1
"Logout"
2
{"PageView":"/home"}
3
{"Click":[120,45]}
4
{"Purchase":{"item_id":7,"quantity":2}}

This is the externally tagged representation, the default. The variant name becomes a JSON key (or, for a unit variant, a bare string). In TypeScript you would model this as a tagged union ({ type: "purchase"; itemId: number }) and check e.type by hand; Serde derives both the encode and the validated decode for you. You can switch to internally tagged, adjacently tagged, or untagged representations with #[serde(tag = "...")] and friends — those are covered in attributes.md and json.md.

Struct kinds and their JSON shapes

The derive handles every shape of struct Rust allows, and each maps to a sensible JSON value:

1
use serde::{Deserialize, Serialize};
2

3
#[derive(Debug, Serialize, Deserialize)]
4
struct Meters(f64); // newtype struct (one field)
5

6
#[derive(Debug, Serialize, Deserialize)]
7
struct Point(i32, i32); // tuple struct
8

9
#[derive(Debug, Serialize, Deserialize)]
10
struct Marker; // unit struct (no fields)
11

12
#[derive(Debug, Serialize, Deserialize)]
13
struct Wrapper<T> {
14
    value: T,
15
    label: String,
16
}
17

18
fn main() {
19
    println!("{}", serde_json::to_string(&Meters(3.5)).unwrap());
20
    println!("{}", serde_json::to_string(&Point(1, 2)).unwrap());
21
    println!("{}", serde_json::to_string(&Marker).unwrap());
22

23
    let w = Wrapper { value: vec![1, 2, 3], label: "nums".into() };
24
    println!("{}", serde_json::to_string(&w).unwrap());
25
}

Real output:

1
3.5
2
[1,2]
3
null
4
{"value":[1,2,3],"label":"nums"}

A newtype struct is transparent: it serializes as its single inner value (3.5, not {"0":3.5}).
A tuple struct serializes as a JSON array.
A unit struct serializes as null.
A generic struct works too: the derive automatically adds a T: Serialize (or T: Deserialize) bound to the generated impl, so Wrapper<T> is serializable exactly when its T is. This is one place the macro is smarter than a copy-paste impl would be.

Key Differences

Aspect	TypeScript / JavaScript	Rust + Serde derive
Who can be serialized	Any value, implicitly	Only types that implement `Serialize`
When that is decided	At runtime, by walking properties	At compile time, by the derive macro
Direction control	Always both ways	`Serialize` and `Deserialize` are separate, opt-in
Nested types	Recursively walked automatically	Each field type must also implement the trait
Deserialization safety	`JSON.parse(...) as T` is unchecked	Missing/mismatched fields are real, recoverable errors
Methods/behavior	Silently dropped (only data survives)	N/A — only the data fields exist; no methods to lose
Generics	Erased at runtime	Monomorphized; derive adds bounds like `T: Serialize`
Cost	Reflection on every call	Zero runtime reflection; code is generated once

Tip: The most useful one-sentence summary for a TypeScript developer: #[derive(Serialize, Deserialize)] is how you make a type “JSON-ready,” and the compiler enforces that everything it contains is ready too.

Why Rust does it this way

Rust has no runtime type information by design — generics are monomorphized away (the opposite of TypeScript’s type erasure), and there is no prototype chain to walk. Pushing serialization into compile-time generated code means it is fast (no reflection), type-checked (you cannot serialize something half-defined), and format-agnostic (the same impl drives JSON, YAML, binary formats, and more). The trade-off is the one line of #[derive(...)] you must remember to write.

Common Pitfalls

Pitfall 1: A nested field type forgot the derive

This is the number-one error. You derive Serialize on the outer struct but forget it on a type it contains:

1
use serde::{Deserialize, Serialize};
2

3
struct Address {
4
    city: String,
5
} // no derive here
6

7
#[derive(Serialize, Deserialize)]
8
struct Person {
9
    name: String,
10
    address: Address, // requires Address: Serialize + Deserialize
11
}
12

13
fn main() {
14
    let p = Person { name: "Ada".into(), address: Address { city: "London".into() } };
15
    let _ = serde_json::to_string(&p);
16
}

The real compiler error (cargo build):

1
error[E0277]: the trait bound `Address: serde::Serialize` is not satisfied
2
    --> src/main.rs:7:10
3
     |
4
   7 | #[derive(Serialize, Deserialize)]
5
     |          ^^^^^^^^^ the trait `Serialize` is not implemented for `Address`
6
...
7
  10 |     address: Address,
8
     |     ------- required by a bound introduced by this call
9
     |
10
     = note: for local types consider adding `#[derive(serde::Serialize)]` to your `Address` type
11
     = note: for types from other crates check whether the crate offers a `serde` feature flag

Fix: add #[derive(Serialize, Deserialize)] to Address too. The compiler note spells out both cases: derive it yourself for your own types, or enable the dependency’s serde feature for third-party types (for example uuid = { version = "1", features = ["serde"] }).

Pitfall 2: Borrowing `&str` fields that outlive the source bytes

It is tempting to deserialize into a struct that borrows from the input (&str instead of String) for speed. That works, but the borrowed data cannot outlive the buffer it points into:

1
use serde::Deserialize;
2

3
#[derive(Debug, Deserialize)]
4
struct Config<'a> {
5
    name: &'a str,
6
}
7

8
fn parse_config() -> Config<'static> {
9
    let data = String::from(r#"{"name":"prod"}"#);
10
    let cfg: Config = serde_json::from_str(&data).unwrap();
11
    cfg // does not compile (error0515): `data` is dropped at end of fn
12
}
13

14
fn main() {
15
    println!("{:?}", parse_config());
16
}

The real compiler error:

1
error[E0515]: cannot return value referencing local variable `data`
2
  --> src/main.rs:11:5
3
   |
4
10 |     let cfg: Config = serde_json::from_str(&data).unwrap();
5
   |                                            ----- `data` is borrowed here
6
11 |     cfg
7
   |     ^^^ returns a value referencing data owned by the current function

Fix: if you need the data to live independently, use owned fields (name: String). Use borrowed fields only when the input buffer clearly outlives the struct. Zero-copy deserialization and #[serde(borrow)] are explored in performance.md.

Pitfall 3: Importing the wrong `Serialize`/`Deserialize`

The names you derive must be in scope and must be Serde’s. A common mistake is to write #[derive(Serialize)] without use serde::Serialize;, or to confuse the derive macro (used in #[derive(...)]) with the trait (used in T: Serialize bounds). With the derive feature enabled, a single use serde::{Deserialize, Serialize}; brings both the traits and the same-named derive macros into scope, which is why that import line appears at the top of nearly every Serde example.

Pitfall 4: Expecting `Debug` and `Serialize` to be the same thing

#[derive(Debug)] gives you {:?} formatting for logs; it is not serialization. They are separate derives. You will frequently see them together (#[derive(Debug, Serialize, Deserialize)]) but each does its own job — Debug output is for humans and is not guaranteed stable, while Serialize output is a real data format you can parse back.

Pitfall 5: Assuming unknown JSON fields cause an error

By default, deserialization ignores fields in the input that your struct does not declare. This is usually what you want for forward-compatible APIs, but it can hide typos:

1
use serde::Deserialize;
2

3
#[derive(Debug, Deserialize)]
4
struct Temperature {
5
    celsius: f64,
6
}
7

8
fn main() {
9
    // The extra "humidity" key is silently ignored.
10
    let json = r#"{"celsius":21.5,"humidity":40}"#;
11
    let parsed: Temperature = serde_json::from_str(json).unwrap();
12
    println!("{parsed:?}"); // Temperature { celsius: 21.5 }
13
}

Real output:

1
Temperature { celsius: 21.5 }

Fix: if you want unknown fields to be a hard error, add #[serde(deny_unknown_fields)] to the struct (see attributes.md). Conversely, a missing required field is always an error — that asymmetry is what makes deserialization safer than a bare as T cast.

Best Practices

Put the derive on the data type, once. Keep #[derive(Serialize, Deserialize)] on the plain data struct/enum and let it propagate through composition. Do not scatter manual impls unless you genuinely need custom behavior.
Derive only the direction you use. Output-only DTOs need just Serialize; config/request types that you only read need just Deserialize. It keeps intent clear and compile times marginally lower.
Pair with Debug. #[derive(Debug, Serialize, Deserialize)] is the workhorse combination — Debug for logging, the Serde pair for the wire.
Prefer owned fields (String, Vec<T>) by default. Reach for borrowed &str / #[serde(borrow)] only when profiling shows it matters; the ownership headaches (Pitfall 2) are rarely worth it up front.
Keep field names matching the wire format, or use attributes — not a second struct. If your API uses camelCase, add #[serde(rename_all = "camelCase")] rather than maintaining a parallel type. See attributes.md.
Enable the serde feature on third-party crates (e.g. chrono, uuid, rust_decimal) instead of writing wrapper types, so their inner types implement the traits directly.
Let the derive add generic bounds for you. For generic types, write the derive normally; Serde inserts T: Serialize/T: Deserialize automatically. Override with #[serde(bound = "...")] only in advanced cases.

Real-World Example

A typical domain model for an e-commerce order: nested structs, an enum with data-carrying variants, a Vec, and a HashMap — all serializable from a single derive on each type, and verified to round-trip.

1
// Cargo.toml:
2
//   [dependencies]
3
//   serde = { version = "1", features = ["derive"] }
4
//   serde_json = "1"
5
use serde::{Deserialize, Serialize};
6
use std::collections::HashMap;
7

8
#[derive(Debug, Serialize, Deserialize)]
9
struct Money {
10
    amount_cents: u64,
11
    currency: String,
12
}
13

14
#[derive(Debug, Serialize, Deserialize)]
15
enum OrderStatus {
16
    Pending,
17
    Shipped { tracking_number: String },
18
    Cancelled,
19
}
20

21
#[derive(Debug, Serialize, Deserialize)]
22
struct LineItem {
23
    sku: String,
24
    quantity: u32,
25
    unit_price: Money, // nested type — also derives the traits
26
}
27

28
#[derive(Debug, Serialize, Deserialize)]
29
struct Order {
30
    order_id: String,
31
    status: OrderStatus,         // enum field
32
    items: Vec<LineItem>,        // collection of nested structs
33
    metadata: HashMap<String, String>,
34
}
35

36
fn main() {
37
    let mut metadata = HashMap::new();
38
    metadata.insert("source".to_string(), "web".to_string());
39

40
    let order = Order {
41
        order_id: "ord_1001".into(),
42
        status: OrderStatus::Shipped { tracking_number: "TRK-9".into() },
43
        items: vec![LineItem {
44
            sku: "BOOK-42".into(),
45
            quantity: 2,
46
            unit_price: Money { amount_cents: 1599, currency: "USD".into() },
47
        }],
48
        metadata,
49
    };
50

51
    // Serialize the whole graph in one call.
52
    let json = serde_json::to_string_pretty(&order).unwrap();
53
    println!("{json}");
54

55
    // Deserialize it straight back into the typed model.
56
    let round_tripped: Order = serde_json::from_str(&json).unwrap();
57
    assert_eq!(round_tripped.order_id, order.order_id);
58
    println!("round-trip OK");
59
}

Real output:

1
{
2
  "order_id": "ord_1001",
3
  "status": {
4
    "Shipped": {
5
      "tracking_number": "TRK-9"
6
    }
7
  },
8
  "items": [
9
    {
10
      "sku": "BOOK-42",
11
      "quantity": 2,
12
      "unit_price": {
13
        "amount_cents": 1599,
14
        "currency": "USD"
15
      }
16
    }
17
  ],
18
  "metadata": {
19
    "source": "web"
20
  }
21
}
22
round-trip OK

One derive per type and the entire nested graph — struct inside struct inside Vec, plus an enum and a map — serializes and deserializes with full type checking. This same Order type is exactly what you would return from a web handler; see how it plugs into HTTP responses in section 16.

Exercises

Exercise 1: Make a type round-trip

Difficulty: Easy

Objective: Get comfortable adding the derive and round-tripping a value through JSON.

Instructions:

Define a BlogPost struct with fields title: String, author: String, tags: Vec<String>, and published: bool.
Make it both serializable and deserializable.
In main, construct a value, serialize it to a JSON string, print it, then deserialize it back and print the resulting struct with {:?}.

1
use serde::{Deserialize, Serialize};
2

3
// TODO: add the right derive(s)
4
struct BlogPost {
5
    title: String,
6
    author: String,
7
    tags: Vec<String>,
8
    published: bool,
9
}
10

11
fn main() {
12
    // TODO: build, serialize, print, deserialize, print
13
}

Solution

1
use serde::{Deserialize, Serialize};
2

3
#[derive(Debug, Serialize, Deserialize)]
4
struct BlogPost {
5
    title: String,
6
    author: String,
7
    tags: Vec<String>,
8
    published: bool,
9
}
10

11
fn main() {
12
    let post = BlogPost {
13
        title: "Rust for TS devs".into(),
14
        author: "ada".into(),
15
        tags: vec!["rust".into(), "serde".into()],
16
        published: true,
17
    };
18

19
    let json = serde_json::to_string(&post).unwrap();
20
    println!("{json}");
21
    // {"title":"Rust for TS devs","author":"ada","tags":["rust","serde"],"published":true}
22

23
    let back: BlogPost = serde_json::from_str(&json).unwrap();
24
    println!("{back:?}");
25
    // BlogPost { title: "Rust for TS devs", author: "ada", tags: ["rust", "serde"], published: true }
26
}

Exercise 2: A data-carrying enum and a deserialization error

Difficulty: Medium

Objective: Observe how struct-variant enums serialize, and see a real error when a required field is missing.

Instructions:

Define an enum Shape with three struct variants: Circle { radius: f64 }, Rectangle { width: f64, height: f64 }, and Triangle { base: f64, height: f64 }. Derive both Serde traits.
Write a function area(&Shape) -> f64 that matches each variant.
Serialize one of each variant and print the JSON alongside its area.
Then attempt to deserialize the invalid JSON {"Circle":{}} (missing radius) into a Shape, and print the error message instead of unwrapping.

Solution

1
use serde::{Deserialize, Serialize};
2

3
#[derive(Debug, Serialize, Deserialize)]
4
enum Shape {
5
    Circle { radius: f64 },
6
    Rectangle { width: f64, height: f64 },
7
    Triangle { base: f64, height: f64 },
8
}
9

10
fn area(shape: &Shape) -> f64 {
11
    match shape {
12
        Shape::Circle { radius } => std::f64::consts::PI * radius * radius,
13
        Shape::Rectangle { width, height } => width * height,
14
        Shape::Triangle { base, height } => 0.5 * base * height,
15
    }
16
}
17

18
fn main() {
19
    let shapes = vec![
20
        Shape::Circle { radius: 2.0 },
21
        Shape::Rectangle { width: 3.0, height: 4.0 },
22
        Shape::Triangle { base: 6.0, height: 2.0 },
23
    ];
24

25
    for s in &shapes {
26
        println!("{} -> area {:.2}", serde_json::to_string(s).unwrap(), area(s));
27
    }
28

29
    // A missing required field is a real, recoverable error.
30
    let bad = r#"{"Circle":{}}"#;
31
    let result: Result<Shape, _> = serde_json::from_str(bad);
32
    println!("{:?}", result.err().map(|e| e.to_string()));
33
}

Real output:

1
{"Circle":{"radius":2.0}} -> area 12.57
2
{"Rectangle":{"width":3.0,"height":4.0}} -> area 12.00
3
{"Triangle":{"base":6.0,"height":2.0}} -> area 6.00
4
Some("missing field `radius` at line 1 column 12")

Exercise 3: Hand-write what the derive generates

Difficulty: Hard

Objective: Prove to yourself that #[derive(Serialize)] produces ordinary code by writing an equivalent impl and confirming it yields byte-identical JSON.

Instructions:

Define a Temperature struct with one field celsius: f64. Derive only Deserialize on it.
Hand-write impl Serialize for Temperature using serialize_struct / serialize_field / end, matching the field name "celsius" exactly.
Define a second struct TemperatureDerived with the same field but #[derive(Serialize)].
Serialize one value of each and assert_eq! that the two JSON strings are identical.

Solution

1
use serde::ser::{Serialize, SerializeStruct, Serializer};
2
use serde::Deserialize;
3

4
#[derive(Debug, Deserialize)]
5
struct Temperature {
6
    celsius: f64,
7
}
8

9
// Hand-written Serialize that mirrors the derive output exactly.
10
impl Serialize for Temperature {
11
    fn serialize<S>(&self, serializer: S) -> Result<S::Ok, S::Error>
12
    where
13
        S: Serializer,
14
    {
15
        let mut state = serializer.serialize_struct("Temperature", 1)?;
16
        state.serialize_field("celsius", &self.celsius)?;
17
        state.end()
18
    }
19
}
20

21
#[derive(Debug, serde::Serialize)]
22
struct TemperatureDerived {
23
    celsius: f64,
24
}
25

26
fn main() {
27
    let manual = Temperature { celsius: 21.5 };
28
    let derived = TemperatureDerived { celsius: 21.5 };
29

30
    let a = serde_json::to_string(&manual).unwrap();
31
    let b = serde_json::to_string(&derived).unwrap();
32
    println!("manual:  {a}");
33
    println!("derived: {b}");
34

35
    assert_eq!(a, b);
36
    println!("identical: {}", a == b);
37
}

Real output:

1
manual:  {"celsius":21.5}
2
derived: {"celsius":21.5}
3
identical: true

Deriving Serialize and Deserialize

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

What derive is, and why it is needed

What the derive actually generates

Serialize and Deserialize are independent

Every field’s type must also implement the trait

It works on enums too

Struct kinds and their JSON shapes

Key Differences

Why Rust does it this way

Common Pitfalls

Pitfall 1: A nested field type forgot the derive

Pitfall 2: Borrowing &str fields that outlive the source bytes

Pitfall 3: Importing the wrong Serialize/Deserialize

Pitfall 4: Expecting Debug and Serialize to be the same thing

Pitfall 5: Assuming unknown JSON fields cause an error

Best Practices

Real-World Example

Further Reading

Exercises

Exercise 1: Make a type round-trip

Exercise 2: A data-carrying enum and a deserialization error

Exercise 3: Hand-write what the derive generates

Deriving `Serialize` and `Deserialize`

What `derive` is, and why it is needed

`Serialize` and `Deserialize` are independent

Pitfall 2: Borrowing `&str` fields that outlive the source bytes

Pitfall 3: Importing the wrong `Serialize`/`Deserialize`

Pitfall 4: Expecting `Debug` and `Serialize` to be the same thing