Explained Simply #17
Serialization
Inside your program, a trip is an object. It sits in memory with its city, its nights and its passengers. But the internet can only carry text. So before the trip can be sent, it has to be converted into text, and when it arrives, it has to be converted back.
The first step is called serialization, and the reverse is deserialization.
Our running example is the travel app. When the user books a trip, the app serializes the trip object to JSON. When the server replies with a confirmed booking, the app deserializes that JSON back into an object it can use.
Everyday comparison: Think of packing a suitcase for a flight. You take your clothes, which are the object, and fold and pack them into a bag, which is the text. The airline can carry the bag, but it can’t carry loose clothes. At the other end, you unpack the bag and put everything back where it belongs.
A worked example
In Python, a trip might look like this in memory:
trip = {"city": "Paris", "nights": 3, "flexible": True}To send it, the program serializes it:
import json
text = json.dumps(trip)
# text is: {"city": "Paris", "nights": 3, "flexible": true}Notice that True became true. Python and JSON write the same value differently, and the serializer knows the rules for converting between them.
When the reply arrives, the program reverses the process:
booking = json.loads(text)
print(booking["city"]) # Paris
What serialization has to handle
Simple values such as numbers, text and booleans convert easily. Other values need thought.
Get ThinkTaught’s stories in your inbox
Join Medium for free to get updates from this writer.
Dates are the classic problem. JSON has no date type, so the date has to become text, such as "2026-10-30". Both sides then need to agree on that format. The international standard ISO 8601 is the one most APIs choose.
Custom objects need rules too. A trip object might hold a link to a hotel object, and the serializer has to decide whether to include the hotel’s details or just its ID.
Round trips
A round trip means you serialize an object and then deserialize it again. Ideally, you get back exactly what you started with. In practice, values can drift. A date might change time zone, a decimal might lose precision, or a field might disappear. Checking that a round trip returns the same values is a good habit when you build an API client.
Unsafe loaders and untrusted data
Some formats can do more than describe data. Certain loaders can even run code when they read a file. That’s dangerous when the data comes from outside your system. For data from the internet, use a plain parser such as JSON, which can only describe values and never run them.
Also, never trust incoming data. Check every field’s type and range before using it. A field that should be a number might arrive as text, and a field that should be present might be missing.
Quick recap
- Serialization turns an object into text. Deserialization turns the text back into an object.
- Your program works with objects, and the network carries text.
- Dates have no JSON type, so agree on a format such as ISO 8601.
- Round trips can drift, so check them.
- Use plain parsers for untrusted data, and validate every field.
One question to take with you
We now know how data is shaped and how it’s moved. But an API also needs rules for how clients ask for data, create it, change it and delete it. Is there a standard way to organise all that? Yes, and it’s called REST.
That’s what the next episode answers: What is REST?
Follow ThinkTaught so you don’t miss it. If something here is unclear, tell me in the comments. We’re learning this together.
