search

alan-turing-institute / simulate-middleware

Simulate middleware service.
http://simulate.readthedocs.io
0 stars 0 forks source link

Should ParameterSpecs and CaseFields serialise their ids? #9

Open klapaukh opened 6 years ago

klapaukh commented 6 years ago

When a parameter spec or case field is returned to a user as part of a case it for display, it doesn't need its id.

However, we might want to keep it if we want to be able to support the following interaction mode in case writing.

PATCH /case/<case id>/<case_field_id>/spec/<parameter spec id> {new state} or PATCH /case/<case id>/<case_field_id> {new state}

This would make it so that you don't need to patch the entire case tree every time.

Also, we could add a second layer of validation for job patching, by making the UI return the case field id it claims that it is patching, to make it easier to validate. Similarly, it means we could create an endpoint like:

PATCH /job/<job_id>/fields/<case_field_id> {new state}

Then you don't need to send the entire list every time.

martintoreilly commented 6 years ago

Does having finer grained end points require multiple API classes or can we handle /case/<case id>/<case_field_id> and /case/<case id>/<case_field_id>/spec/<parameter spec id> with a single endpoint?

Do we not need IDs to parse a parameter spec from the JSON even from a PATCH to /case/<case id>/<case_field_id> (or is that what the last part of your comment it)?

Potentially making the above irrelevant, did we not say that we'd make a new case version for every edit (i.e. not amend an existing case)?

klapaukh commented 6 years ago

I believe that we would need multiple API classes.

We don't need parameter spec ids to change or understand anything above them in the hierarchy. This includes case fields, cases, and job parameter values.

As far as the last point goes. I don't believe that that makes those things irrelevant. I think that a case can remain in an EDITING mode for more than one request. During this time it cannot be used (i.e. turned into a Job [except perhaps for testing purposes - not sure how I imagine this looking]). All changes which are made during one notional READY -> EDITING -> READY cycle would be grouped into a single version increment. I believe that this is more reasonable than requiring that all changes in one version step for a case must be done in a single request.

martintoreilly commented 6 years ago

Agreed on the explicit conversion from draft to ready to deploy case.