You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered: