-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposing new Types #89
Comments
some interesting items on this list. would like to hear from others on which seems compelling additions. as mentioned elsewhere here, the recommended approach is to create a working valid extension that is backward-compatible. then we can all see what it takes to implement it and test it against existing client applications to make sure the fallbacks are acceptable on all sides. a side note: since HAL-FORMS might be used in UI settings as well as API settings, you should be sure that each extension has a viable solution for both use cases. we've tried to steer clear to writing specs that tell implementors what the UI should look-like and focus on how response consumers can recognize the feature and deal with it in both API and UI cases. looking forward to seeing some of this in action. |
Do you mean an implementation of the spec with the mentioned additions when you write: "a working valid extension that is backward-compatible"? If yes, I'm currently working on one and will report back once it is finished. |
I found the need for two more types:
|
I'm missing some types and would like to get some feedback if they might be implemented in the spec.
data:image/png;base64,...
. A client interface would render the image and a text input and / or a file upload.For further aid, I would also like to propose a new field on properties:
mimeTypes
which would be OPTIONAL and may contain an array of MIME-types. This would help clients to know which types forimage
andfile
are accepted.The text was updated successfully, but these errors were encountered: