-
Notifications
You must be signed in to change notification settings - Fork 1
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
Proposed extension: non-RDF payloads #5
Comments
I'd raise a question whether the extension is supposed to cover non-RDF payloads or to be protocol specific, i.e. HTTP targeted extension. Hydra tries to be as protocol agnostic as possible and while there are some concepts known from HTTP (headers, method), these concepts are also available in other protocols. I acknowledge multi-part requests somehow HTTP specific. Having a description of a multi-part body (either for HTTP request/response handling or simple email description) still is an interesting topic of an extension. |
I think you're mixing two concerns: resource representations and protocol. Multi-part may be specific to HTTP but otherwise non-RDF means pretty much that. Anything which is not RDF. Most prominently image/video payloads or maybe formats such as PDF/xls/doc, etc. Does not matter if the protocol would be HTTP, FTP or Gopher if we had the means to describe such operations |
Ok, indeed few things got mixed here. Leaving multi-part aside for a while, as for simple PRD/XLS/DOC etc. it is already doable with hydra by using header specification - there you can provide i.e. MIME types that are expected or returned with |
We don't need to decide now. The "extension" could also become more of a "best practices" document showing more concrete examples which maybe would be to verbose for the core spec. How does that sound? |
Continuation of HydraCG/Specifications#199
I think it's a worthy extension candidate to build an independent vocabulary for describing resources in more flexible manner, which could replace the values for
expects
/returns
in operation which don not work with RDF representationsA prominent idea mentioned before would have been multi-part requests or precise constraints of binary bodies (such as constraining size and dimensions of images)
The text was updated successfully, but these errors were encountered: