Phil Sturgeon as a new post to his site today talking about the importance of serialized API output and why it's important to think about what to share and how they're shared.

One section that seems to get a lot of feedback and questions is when I talk about serialization, which I refer to as “adding a presentation layer to your data”. [...] To PHP developers, they often consider serialization to be using the serialize() function. Yes, this is one form of serialization, but it’s not the only one. Another common serialization approach is of course to use the json_encode() function. [...] Excuse the drastically simplified chunk of code here, but the point is we’re taking a model (probably using an ORM) and returning the result directly. This seems fairly innocent, but leads to a range of problems.

He suggests that, when thinking about the data coming out of your API, you have to assume that every possible value could be shared if models are output directly. He gives the example of user passwords which, obviously, don't need to be shared at all. He includes an example of formatting the output with the Fractal library and why using something like that is important. He covers some of the topics to think about including attribute data types, renaming fields to make them more clear, the ability to pull from multiple data stores and the ability to version serializers. He ends the post with links to a few different serialization formats and some solutions (not just PHP ones) that can be used for the sort of handling he recommends.