While service definitions do provide a way to include custom fields with different kinds of service requests, there are many situations where new fields are needed in other parts of the specification. In many cases, these custom fields could be candidates for additions or revisions to the spec, so it may make sense to allow for them to help drive the spec forward.
However, there should be a clear distinction between fields which are defined in the spec and those that are custom or unique to certain situations. In order to do this, it would be beneficial to define a convention for naming these custom fields and for ensuring that clients can ignore them as needed.
While service definitions do provide a way to include custom fields with different kinds of service requests, there are many situations where new fields are needed in other parts of the specification. In many cases, these custom fields could be candidates for additions or revisions to the spec, so it may make sense to allow for them to help drive the spec forward.
However, there should be a clear distinction between fields which are defined in the spec and those that are custom or unique to certain situations. In order to do this, it would be beneficial to define a convention for naming these custom fields and for ensuring that clients can ignore them as needed.
Here's a good example of this from the !OpenStates API: http://openstates.org/api/#extra-fields
Discussion thread: http://lists.open311.org/groups/discuss/messages/topic/3HCsNqI75HgNqVYaMaxubQ