rest_prepare_post is where you add a field without breaking one

Adding data to an existing REST response by filtering the prepared object is tempting and is the wrong hook — there is a registration function that also documents the field in the schema.

register_rest_field( 'post', 'reading_time', array(
    'get_callback' => function ( $post ) {
        return turkerdev_get_reading_time( $post['id'] );
    },
    'schema'       => array(
        'description' => __( 'Estimated reading time in minutes.', 'turkerdev' ),
        'type'        => 'integer',
        'context'     => array( 'view', 'edit' ),
    ),
) );

The schema entry is what makes the field appear in the OPTIONS response, so a client can discover it rather than being told about it in an email. The context array controls whether it appears in a list response, which matters for anything expensive — a field computed per post in a list of a hundred is a hundred computations. Removing a field once clients depend on it is a breaking change, so the schema is a contract rather than documentation.