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
{{ message }}
This repository has been archived by the owner on Dec 31, 2020. It is now read-only.
After filing issues #217, #218 and #219, I'm sort of wondering why is the attachment endpoint needed at all. It feels weird to have two different entry points to what is essentially the same thing. The post_attachment endpoint could return a file directly instead of redirecting to the attachment endpoint.
If a post needs to reference a specific attachment from another post, it could do so by specifying the post's id, version id, attachment name, and an optional content-type. This would have the added advantage of making it possible to reference an attachment without a specific content-type, leaving the negotiation up to the client using the Accept header. Something that isn't possible when referencing attachments directly with their digest. This could even be an extension of the links/deep-links that will be added in 0.4 (I don't know enough about them to know if this could be a use case or not).
I can understand that the attachment endpoint would have been needed in 0.3 to test whether a specific file was already uploaded, but I can imagine that searching posts by digest is something that will be allowed by complex queries in 0.4 (correct me if I'm assuming wrong here).
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
After filing issues #217, #218 and #219, I'm sort of wondering why is the
attachment
endpoint needed at all. It feels weird to have two different entry points to what is essentially the same thing. Thepost_attachment
endpoint could return a file directly instead of redirecting to theattachment
endpoint.If a post needs to reference a specific attachment from another post, it could do so by specifying the post's id, version id, attachment name, and an optional content-type. This would have the added advantage of making it possible to reference an attachment without a specific
content-type
, leaving the negotiation up to the client using theAccept
header. Something that isn't possible when referencing attachments directly with theirdigest
. This could even be an extension of the links/deep-links that will be added in 0.4 (I don't know enough about them to know if this could be a use case or not).I can understand that the
attachment
endpoint would have been needed in 0.3 to test whether a specific file was already uploaded, but I can imagine that searching posts bydigest
is something that will be allowed by complex queries in 0.4 (correct me if I'm assuming wrong here).The text was updated successfully, but these errors were encountered: