search

HydraCG / extensions

3 stars 1 forks source link

Proposed extension: non-RDF payloads #5

Open tpluscode opened 3 years ago

tpluscode commented 3 years ago

Continuation of https://github.com/HydraCG/Specifications/issues/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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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?