Skip to content
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

Open
tpluscode opened this issue May 25, 2021 · 4 comments
Open

Proposed extension: non-RDF payloads #5

tpluscode opened this issue May 25, 2021 · 4 comments

Comments

@tpluscode
Copy link
Collaborator

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 representations

A prominent idea mentioned before would have been multi-part requests or precise constraints of binary bodies (such as constraining size and dimensions of images)

@alien-mcl
Copy link
Member

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.

@tpluscode
Copy link
Collaborator Author

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

@alien-mcl
Copy link
Member

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 Content-Type header. This and RDF class expects/return constructs are the options now.
I'm not sure what other, more sophisticated approaches could be provided.

@tpluscode
Copy link
Collaborator Author

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants