HydraCG/Specifications

expectHeader usage

Closed this issue · 5 comments

Describe your API requirement

I've been looking for some documentation on the expected usage of the hydra:expectsHeader and hydra:returnsHeader properties, but to no avail. Is any available? I was thinking of potentially using expectsHeader to state that an Authorization header should be provided on protected routes but I am not sure whether that is appropriate.

I'm also surprised that the properties only allow one value (though I don't have a use case for more than one at this point). Can anybody explain why that is?

The headers have not really been finalised. Not that its rdfs:range is not defined so it's a little free-form right now

I'm also surprised that the properties only allow one value (though I don't have a use case for more than one at this point).

I don't see that it does. You can have multiple values

{
  "expectsHeader": [ "authorization", "X-Foo" ]
}

Again, the semantics of the values are undefined at this point. Might be string, or maybe something more sophisticated but up to the application to understand the semantics

According to the latest draft of the spec it has a range of "xsd:string", unless I'm mistaken?

Is it worth coming up with an idea of a possible spec? I notice that the HTTP in RDF draft spec includes some header classes but I saw in another issue that there was some reluctance to use those definitions in Hydra.

Indeed, I looked at the HTML spec and apparently it's not in sync. I that listing is generated from the JSON-LD 🤔. @alien-mcl ?

Is it worth coming up with an idea of a possible spec?

Of course. Let's revisit the previous discussion.
What are your specific requirements? What do you need out of the header descriptions?

Indeed, I looked at the HTML spec and apparently it's not in sync.
I that listing is generated from the JSON-LD

Well, it should be that way. I'll have to figure it out why it's not working as it should.

I'm also surprised that the properties only allow one value

In RDF you can always come with more values. As @tpluscode provided an example for JSON-LD, you're free to give a set of values. I'd be cautions with RDF lists though.

I notice that the HTTP in RDF draft spec includes some header classes
but I saw in another issue that there was some reluctance to use those definitions in Hydra.

We didn't want to stick to HTTP to much. Headers are concept existing in various scenarios thus it felt OK to have it reflected in hydra, but digging deeper within the HTTP specification seemed to much for a generic vocabulary.

I've been looking for some documentation on the expected usage of the
hydra:expectsHeader and hydra:returnsHeader properties, but to no avail.

No special examples were provided as it seemed these terms were pretty simple.
Each just gives a set of header names either expected or returned by an operation. No more, no less.
It's more of a union of all possible header names that can be expected or returned as final set may vary at runtime, depending on various circumstances (i.e. user priviledges, etc.).

Feel free to ask for more details - we'll try to address these requirements of yours.

That all makes sense, really all I want to be able to do is provide a set of possible header names as you describe, I was just a bit confused by the "xsd:string" range. I'm still getting to grips with the Hydra and RDF specs, I didn't realise that RDF allows multiple values by default. Thanks for clarifying.