Create a GET /restrictions endpoint for Operator

[punamverma]

Operator should be able to query a restriction by constraint id.

[nasajoey]

so this is for the NUSS client side API, not the USS spec. Does that sound right?

[punamverma]

Yes, this issue was created for operator to be able to GET the constraints from a USS. Priya mentioned CONSTRAINT_MANAGER will also need to GET the constraints that it PUTs. Not sure if they need to be separate endpoints for an operator and for CONSTRAINT_MANAGER.

[nasajoey]

OK, back on this one. Will try to address tomorrow morning.

[nasajoey]

OK, @punamverma please take a look at this commit. Is this a reasonable approach? Just copied the old manager_constraint endpoints and updated to point to correct model and renamed. There is a swagger problem pointing to an external domain, so I need help with that. I think you know how to fix that?

Error resolving $ref pointer "https://raw.githubusercontent.com/nasa/utm-apis/v4-draft/utm-domains/utm-domain-geojson.yaml#/definitions/ConstraintMessage". Token "ConstraintMessage" does not exist.

[punamverma]

@nasajoey The Constraint message is under utm-domain-commons.yaml

https://raw.githubusercontent.com/nasa/utm-apis/v4-draft/utm-domains/utm-domain-commons.yaml#/definitions/ConstraintMessage

I guess thats what you wanted to be resolved. Pleas let me know. Thanks

[punamverma]

@nasajoey I committed the correct link for ConstraintMessage.
However, I was wondering if we need a POST /restrictions for operator. I think he just needs to GET. For PUT we have an endpoint for Constraint Manager in Public Safety spec.

[nasajoey]

@punamverma is this still a question? I don't think operator will be POSTing restrictions, unless I am misunderstanding need/use case.

[punamverma]

Hi @nasajoey ,
Along with GET /restrictions endpoint, you have added POST and PUT endpoints too, which are not needed for an Operator. However, Operator only needs GET /restrictions endpoint. Hence, I was asking if that was intentional, or do you wan too remove it.
Thanks

[nasajoey]

@punamverma please see if that last commit finalizes this or not.

[nasajoey]

@punamverma pinging again. would like to close out. @issmith1 or @myspri may also take a look so we can close this.

[issmith1]

Assignee (currently Shankar) ensure there is, or create a test for this endpoint. Postman (see Ops Lifecycle test) is a reasonable impl, then close out.

@myspri may want to create JIRA to manage this in our sprint.

[myspri]

@nasajoey @punamverma there are two pieces to this, both of which do not need changes to uss-api.

1. This could be an NUSS operator api that allows operators to ask USS about known UVR (a.k.a) DR
2. be a part of public safety api, that allows someone like FIMS to ask for constraints that were issued by this specific USS.

@punamverma you might want to consider moving this issue under public-safety.

[punamverma]

@nasajoey @myspri We can close it, as this issue was for operator. And, I see a GET /restrictions for operator.
And , open a new one for the one @myspri mentioned - "be a part of public safety api, that allows someone like FIMS to ask for constraints that were issued by this specific USS."
Thanks.

[issmith1]

But does the operator-api's /restrictions endpoint have at least 2 tests? (Pos and Neg)

[punamverma]

No @issmith1 ..its not implemented yet.

[issmith1]

note Dynamic Restrictions is now renamed to UAS Volume Reservation (UVR).
We can consider the priority of renaming this endpoint