Align to the official specification#27
Conversation
| resource_type: models.ResourceType = Query(default=None), | ||
| _forbid = Depends(iri_router.forbidExtraQueryParams("name", "description", "group", "offset", "limit", "modified_since", "resource_type")), | ||
| current_status: models.Status = Query(default=None), | ||
| capability: List[AllocationUnit] = Query(default=None, min_length=1), |
There was a problem hiding this comment.
Should the param name be "capabilities"? How does it match a resource? If all the queried caps apply or also if only some apply?
There was a problem hiding this comment.
The name matches the spec (capability) unless we change the spec. According to the spec, the user is able to specify:
/api/v1/status/resources?capability=bytes
/api/v1/status/resources?capability=bytes&capability=node_hours
It can match resources that have at least one capability whose units satisfy the filter, and when multiple units are provided, they are treated as AND / OR (???) semantics. Based on the spec description, I would treat it as AND. (would be great to document this better)
- name: capability
in: query
description: Return only resources with this capability.
required: false
schema:
type: array
items:
type: string
There was a problem hiding this comment.
Let's ask @jmacauley @pmrich. How should the Facility interpret multiple values? AND or OR?
There was a problem hiding this comment.
Two things:
- When I implemented the
capabilityquery parameter on/status/resourcesI used the URN as the parameter to match the exact entity. I guess I could have used id as well uuid. What are you using to match?
- I used the list format
/status/resources?capability=uri_1,uri_2,uri_3, which evaluated asORresulting in resources being returned if they contained any of the three capabilities.
There was a problem hiding this comment.
As for how we would want this to behave, I think AND makes more sense to me. Though I suppose you can get the same effect by applying OR and the the user has to filter the result for the specific resources they need. It seems that returning the OR would cover both the AND and OR cases reasonably, even if I expect AND to be more common.
…scovery endpoint This pull requests includes: - Implement /api/v1 to list metadata; - Implement /facility api (most fields are optional, and implemented based on the specification) - Capabilities, project include forbidExtraQueryParams to make validation happy. - Parse Raw query_string (catch duplicate keys) - Add HTTP 304 handling and return correct header
…scovery endpoint This pull requests includes: - Implement /api/v1 to list metadata; - Implement /facility api (most fields are optional, and implemented based on the specification) - Capabilities, project include forbidExtraQueryParams to make validation happy. - Parse Raw query_string (catch duplicate keys) - Add HTTP 304 handling and return correct header
Move common validators and base models into routers/dependencies and update imports across routers and schemas to use the new shared location. This keeps API behavior unchanged. No functional API changes — purely structural and validation hygiene:
4 participants
This includes:
API compliant with the official spec;
Github Validation with schemanthesis (API is fully compliant)
Enable/disable opentelemetry
Force py version to be 3.14
Many validation fixes and changes to remain close to the official spec