-
Notifications
You must be signed in to change notification settings - Fork 180
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
New field in links (method, headers, body) #1253
base: dev
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks generally good, but a couple of thoughts (for here and partially also the API):
- headers: Shouldn't this be strictly just be a
Map<string, string>
? - body: Shouldn't this allow anything? Why is it only an object? Why can't it be a string or an array for example?
- Should we have a central place where we define links so that it's not so repetitive?
I used the same spec as per STAC API to be aligned since the initial issue was about being in line with STAC API.
I moved link object definitions from item, catalog and collection to common metadata page |
Maybe that's something we should actually bring up in the API and change there, too...
Not sure whether that's a good idea. That would need a broader change also in the schema as it implies links can now be used in Assets, Providers, Links itself, ... basically everywhere. I don't think that's intended. |
| type | string | [Media type](../catalog-spec/catalog-spec.md#media-types) of the referenced entity. | | ||
| title | string | A human readable title to be used in rendered displays of the link. | | ||
| method | string | The HTTP method required to be supported by the target resource. `GET` by default | | ||
| headers | object | The HTTP headers required to be sent by the target resource. | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't use the object type in the spec, instead we use Map<string, *>
(applies to headers and body for now)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
headers: Map<string, string|array<string>>
{a: "b"}
translates to:
a: b
{a: ["b", "c"]}
translates to:
a: b
a: c
This could hopefully also be clarified in the STAC API spec.
body: Any type allowed
Also needs to be updated in the STAC API spec.
Discussion in STAC meetup: use |
Related Issue(s): #1198
Proposed Changes:
method
,headers
,body
fields inlinks
objectsPR Checklist:
or a CHANGELOG entry is not required.
and I have opened issue HTTP headers in links as dictionary of arrays to support multiple values stac-api-spec#435 to track the change.