search

panoptes-organization / monitor-schema

MIT License
2 stars 4 forks source link

Update workflow vs. rename workflow? #6

Open vsoch opened 3 years ago

vsoch commented 3 years ago

It looks like there is an update workflow view (intended to be done from the interface?) and then another API view to just rename the workflow - should we have both of these or perhaps just an update API endpoint that can handle custom parameters (such as the name?)

fgypas commented 3 years ago

This depends on what id we will use. See https://github.com/panoptes-organization/monitor-schema/issues/5#issuecomment-745892025 (Autoincremented or hash) The rename is done for the hash from the UI.

vsoch commented 3 years ago

Could you explain to me the purpose / reason for this? I'm not understanding why you would need a randomly generated hash and an auto-incremented database id. I can probably better think about this question if I understand that.

fgypas commented 3 years ago

OK, forget about the hash ID. I was confused and I thought that we were using this to update the status from snakemake to panoptes.

Regarding the current issue, I think we can use just one /update endpoint that handles custom parameters.

vsoch commented 3 years ago

Sounds good! And to be specific, it would be a POST /m1/workflow/<workflow-id/ (distinguished by the POST, without an /update suffix.

fgypas commented 3 years ago

Shouldn't it be PUT (not POST)?

vsoch commented 3 years ago

Yes! Sorry about that, I was starting with the original API views as a template, and I forgot to make a change from the original post. I just updated the PR for the endpoint to be PUT.

fgypas commented 3 years ago

No problem and thanks a lot :)