Job patching should validate the inputs

alan-turing-institute / simulate-middleware

Simulate middleware service.

http://simulate.readthedocs.io

0 stars 0 forks source link

Job patching should validate the inputs #6

Open klapaukh opened 6 years ago

klapaukh commented 6 years ago

PATCH /job/ should check that:

[ ] The parameter being set exists in the case
[ ] The parameter has the prefix, suffix, and label processed correctly (the name is prefix + label (or name if label is not present) + suffix
[ ] If the parameter has a min or max that is adhered to.

martintoreilly commented 6 years ago

@klapaukh What are your thoughts on how closely the endpoints should support a CRUD model? If I recall correctly, the POST /job/ only creates a new job with name, author, case_id. I feel we should probably support providing a fully populated job for this endpoint. In this case, we should share validation code with the PATCH (and any future PUT endpoint).

klapaukh commented 6 years ago

As you said, the current version of POST does not support the creation of a fully populated job.

I like the idea of not supporting the full specification of a job with POST. And also not having a PUT. I think that it makes it easier because there is one way of doing each thing.

However, equally, I understand that as the project grows it may want to provide options to ensure that front ends and workflows different from the ones we are using can be easily supported. In which case we would want the functionality you mentioned.

martintoreilly commented 6 years ago

So on the one hand I totally support the "do it when/if you need it" approach. On the other hand I'm thinking about the expectations of the functionality of a REST API with create/read/update semantics (though we also don't yet support delete and would likely only want to do a soft delete). I don't feel super-strongly about this so happy not to add work when we're tight on time. Would be nice to capture some of the requirements / gotchas as an issue though (e.g. "these fields aren't user settable").

klapaukh commented 6 years ago

Hmmmm..... no matter what we do, having the documentation clear on what the limitations are is definitely really important. I am currently working on documenting what is currently implemented and how it works in the project README. Someone should probably look over that to make sure that it is sensible and clear on a lot of these issues.

martintoreilly commented 6 years ago

It would be worth fleshing out the ticket at https://github.com/alan-turing-institute/science-gateway/issues/12 to specify what the docs should contain.