-
Notifications
You must be signed in to change notification settings - Fork 0
Forms. Do we need them?
James Pozenel (@lectrotext)
Kris Kleva (@klevland), Pete Gamache (@gamache), Kevin Swiber (@kevinswiber), Mike Kelly (@mikekelly85), Dmitry Pavlov (@zeldigas), many more
-
Short answer: they are not a mandatory part of the media-type, but that information still need to be somewhere (in docs, profile etc.).
-
Debate on forms vs other documentation approaches.
Forms just a way to represent information about affordance (action) to a client that is embedded in media-type. To operate properly client should know what and how to send to the server to perform an action and forms are just one opportunity to tell client about that in a dynamic way.
Other approaches is to store that information in different place:
- in human readable documents
- as a separate linked resource
- profile
For "hard coded" client that can't change it's behaviour dynamicly, e.g. fill new parameters that appeared in forms, they are not very usefull and can just be a markers of action availability. But that information allows us to implement more dynamic clients that know how to deal with changing parameters (for example they build dynamic UI for user interaction).
- http message compression can greatly reduce the size of the message
- For large forms and for those that do not change often it's a good idea to be able to move forms (each one or as a whole section) to separate resource and just link to them instead of inclusion in the message. This appoach will allow us to use http cache controls and avoid every time loading. Current media-types with forms (e.g. Siren) do not support that yet, but we should consider adding support for that.
Possible solution for that problem is to extend form description language to be able to say that a parameter should conform to some schema (e.g. json schema) instead of separate fields description.