-
-
Notifications
You must be signed in to change notification settings - Fork 75
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
Implement File API #9
Comments
data/download as a URI or embedded base64 data? The former is probably better (fewer bytes to download) |
As URI. We might want to support embedded base64 data in future versions (maybe with framing). |
The current serialization for a {
"@id": "http://nohost/plone/document.pdf",
"@type": "File",
"title": "My PDF document",
"UID": "abef59538b3749debad950c3c5d35224",
"...": "...",
"file": "http://nohost/plone/document.pdf/@@download/file"
} So a I would propose to change the serialization to something that is slightly more in line with the format used for deserialization (upload): {
"@id": "http://nohost/plone/document.pdf",
"...": "...",
"file": {
"filename": "document.pdf",
"content-type": "application/pdf",
"size": 65536,
"download": "http://nohost/plone/document.pdf/@@download/file"
}
} That way, clients would have the necessary information to render a decent download link, including icon, filename and size without doing a second request. The contract would then be that the client can do a The same principle could probably be applied to images scales. |
@lukasgraf you proposal looks good to me. It is essential that serialization/deserialization use the same structure. I guess from a HTTP spec perspective it would be correct if the client would send a GET request to "http://localhost:8080/Plone/document.pdf/@@download/file" with Accept "application/pdf" header. Though, since it works without the Accept header in Plone as well I guess we don't have to be pedantic about it. |
@tisto I agree, this would be the proper behavior. But since I'll start working on this (and Images) then, PR coming up. |
Closed by #115 |
The text was updated successfully, but these errors were encountered: