Input parameters in the Index endpoint

[jiripetrzelka]

Would it be possible to add the following optional input parameters to the Index endpoint?

• global_id
• activity_type
• activity_attributes

[janinamincer-daszkiewicz]

Could you give some arguments supporting this change

[jiripetrzelka]

1. Ability to retrieve data only for studies/traineeships - In our system, these are separate components with their owns rights. For example, if a user with the right to retrieve traineeship nominations (and not the SMS nominations) clicks on a refresh button then without this attribute the script has to invoke the get endpoint for each mobility found in the Index endpoint to find out whether it is SMS or SMP/SMT. The argument is therefore to limit unnecessary traffic. The situation is similar with the activity_attributes parameter.

2. Consistent approach with attributes in https://github.com/erasmus-without-paper/ewp-specs-api-omobility-las/blob/stable-v1/endpoints/index.md - if global_id is necessary for the LA API, it will certainly be necessary for this API too. It is also quite confusing that the mobility_type in LA corresponds to activity_attributes in this API. If it is not too late, I would suggest to keep the same attribute name (mobility_type) and values in both APIs. The argument is: Clearer understanding and reduction of the probability of implementation errors.

[janinamincer-daszkiewicz]

It is also quite confusing that the mobility_type in LA corresponds to activity_attributes in this API. If it is not too late, I would suggest to keep the same attribute name (mobility_type) and values in both APIs. The argument is: Clearer understanding and reduction of the probability of implementation errors.

We spent ages and exchanged hundreds of email negotiating names and values of these two new fields with DG EAC and the business oriented partners. The naming in this API is more relevant than in LA. We will rather change it in LA.

[jiripetrzelka]

I agree, changing the names, even if in the LA API, would still help the overall consistency and understandability of both APIs.

[umesh-qs]

@jiripetrzelka I believe the use case you have mentioned is more of access control that should be governed by the application.

What we mostly do refresh mobility by modified date, but also provide option to pull by data by partners involved. What to display to the end user is handled by the application. In fact number of calls to API will be more with these filters.

[jiripetrzelka]

I would like to ask the designers of this API the other way round: What makes you think that the global_id and activity-attributes are necessary for LAs but not for Nominations?

As to the activity-type:

• @umesh-qs, the number of total requests may be higher but it may also be lower. It depends on the number of nominations for each activity type and the use case. I agree that this argument is not bullet-proof but it is not completely false.
• However, if we consider that for now we have decided to work with additional requirements in Factsheet only in regard to SMS mobilities stating that SMP mobilities are different and will be dealt with later in the future then I think it would be reasonable to assume that implementation priorities for this API may also differ for SMS and SMP and that some implementers may decide to first concentrate on SMS nominations and only later on SMP nominations. I don't agree that it is just a matter of access control. You may need to fetch only SMS or only SMP nominations for various other reasons.

[umesh-qs]

@jiripetrzelka Number of requests will still be higher for the index API if additional filters are added. When you say lower, I assume you mean the amount of data transfer for each call will be lower. But that will not be significant.

There might be use cases where additional filters might be helpful. But until we have a concrete use case, I would not want to make changes to the index API

[jiripetrzelka]

I would like to ask the designers of this API the other way round: What makes you think that the global_id and activity-attributes are necessary for LAs but not for Nominations?

@janinamincer-daszkiewicz Please consider this question to be a feedback to the pull request of version 3. I still think that having these parameters would be useful.

[janinamincer-daszkiewicz]

Accepted. I hope for more comments from the providers.