versioning update requests

[BavoNootaert]

The update endpoint currently does not contain any way to determine the intended order of requests. For this to work, (and as mentioned during the meeting on 24 may) the client has to make sure it doesn't send any requests in parallel, or resends a failed request after another request has already been sent successfully.

Then the server has to trust the client is well-behaved. I don't think this is a good idea. A server should rely only on the information that is contained in the message it receives, not on anything else. Placing too much trust on the client opens the door for errors that are hard to debug, and discussions over who sent what. Remember that in this case it is the client who asks the server to change data that is actually the responsibility of the server. Also, in the future there could be far more different clients than we have now, so the API should be as robust as possible.

I think a better solution would be to either include version numbers, separate for each type of update request, or for the sending HEI to GET the latest mobility data from the receiving HEI upon receiving an update request (for which in this case only one type would suffice).

I recall from the last meeting that most teams are not yet ready to implement update requests, so I'd like to invite @erasmus-without-paper/all-members to share their thoughts on this.

[wrygiel]

If I understand correctly, you are talking about edit conflicts.

In partcular, you are considering a scenario in which a receiving HEI attempts to update a single mobility at the same time in parallel requests. In this case, one of these updates will probably fail (the server will respond with HTTP 409 Conflict response). Each update request contains (or should contain) a "previous state" description, added explicitly to prevent such edit conflicts. For example, see here and here.

Could you provide some example requests of what you are proposing? I'm not sure what you mean by "version numbers", and how they would help (compared to the existing countermeasures).

[NicoVanMoortel]

At this moment it is not yet clear for us how the process (the approval by the three parties of a mobility) is going to function. Which use cases are supported? And I think that is part of the reason for this question. The beginning is clear. A sending institution nominates a student. But what can happen after that?

• If the receiving institution agrees, what do they do?
• What if a receiving institution approves a version of the LA which is different from that known in the sending institution?
• What if no approval is received?
• What if the sending institution wants to change the LA (maybe after approval)? How do they send the changes? How do they get an approval?
• What if changes are made at the receiving institution? What if the receiving institution approves these changes before any other?
• ….

On some question we (think we) know the answer. Some are less clear. And these are just some of the cases. An analyses that describes this flow would be useful.

Is it an option to organize a skype meeting on this subject?

[wrygiel]

If the receiving institution agrees, what do they do?

I assume you are talking about nomination, not the LA? If so, then they send the update-statuses-v1 update request with <new-status>live</new-status>.

What if a receiving institution approves a version of the LA which is different from that known in the sending institution?

It will get a HTTP 409 error in response to their approve-components-studied-draft-v1 request.

What if no approval is received?

Well, I guess the sending coordinator calls the receiving coordinator to ask why. Note, that the receiving coordinator may also use the "standard channel", and send the approval by email. Using EWP is not required.

What if the sending institution wants to change the LA (maybe after approval)? How do they send the changes? How do they get an approval?

They publish their new version in latest-draft-changes and latest-draft-snapshot elements. They notify the partner by calling partner's CNR API. The partner fetches the new version. The partner can also see that this new version hasn't been yet approved by himself. If the partner approves this new version, he sends the approve-components-studied-draft-v1 update request again.

What if changes are made at the receiving institution? What if the receiving institution approves these changes before any other?

In our model, receiving institution cannot make changes, nor approve changes by itself (because it is the sending HEI who is the master of the mobility). Receiving institution can only send suggestions.

Is it an option to organize a skype meeting on this subject?

Sure! It's a difficult topic.

[kamil-olszewski-uw]

I allow myself to close this thread. The entire thread references an update method, which is no longer present in the Outgoing Mobilities API. The update endpoint survives in the Outgoing Mobility LA API, and while there are some meaningful and still valid arguments at the client-server level, they refer to objects that no longer exist or have changed.

We already have one more recent thread on LA updates that addresses similar issues: erasmus-without-paper/ewp-specs-api-omobility-las#8