Split Serialization and Deserialization

[michaeldcanady]

currently for a Parsable it has to implement both serialization and deserialization, and while technically there are work arounds to only implement on or the other within golang it's preferred to have an interface only implement what is minimally required.

current:

// Parsable defines a serializable model object.
type Parsable interface {
	// Serialize writes the objects properties to the current writer.
	Serialize(writer SerializationWriter) error
	// GetFieldDeserializers returns the deserialization information for this object.
	GetFieldDeserializers() map[string]func(ParseNode) error
}

proposed:

// Serializable defines a model that can be serialized
type Serializable interface {
	// Serialize writes the objects properties to the current writer.
	Serialize(writer SerializationWriter) error
}

// Deserializable defines a model that can be deserialized
type Deserializable interface {
	// GetFieldDeserializers returns the deserialization information for this object.
	GetFieldDeserializers() map[string]func(ParseNode) error
}

// for compatibility
// Parsable defines a serializable model object.
type Parsable interface {
	Serializable
	Deserializable
}

[baywet]

Hi Michael Canady (@michaeldcanady)
Thank you for using kiota and for reaching out.

Beyond conforming with Go standard practices, what would this enable?

[michaeldcanady]

Vincent Biret (@baywet) I believe the pros to this change are:

1. cleaner interface - the interfaces will now clearly state their requirements.
2. Clearer models - at the moment unless explicitly detailed or known to the user, one could reasonably get an unexpected error when trying to serialize/deserialize models that don’t support this capability (ask for permission vs ask for forgiveness)

Let me know if you need more information or have any questions/concerns and thank you in advance!

[baywet]

Thank you for the additional information.

For more context, these interfaces were never meant to be used by humans. They are only here to support the generated code.

With that change, would you expect models that are only ever received from the REST API (never used in a request body) to implement only the Deserializable interface?