Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

N°5370 - Improve feedback when updating objects via REST without changes #225

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

larhip
Copy link
Contributor

@larhip larhip commented Aug 5, 2021

When updating an object via REST the feedback is always "updated", doesn't matter whether there is a real change.

It might be interesting to give a feedback via rest whether the object has been changed or not, just like it is in the UI.

This PR checks whether an object is modified and set message to "unchanged" if not.

@piRGoif piRGoif added enhancement New feature or request API labels Aug 5, 2021
@Molkobain Molkobain self-assigned this May 3, 2022
@Molkobain
Copy link
Contributor

Hello Lars, I'll check this PR on friday, would you update/rebase you branch on develop in the meantime? Thanks

@larhip larhip force-pushed the feature/rest_update_without_changes branch from 5695db0 to 8645e6a Compare May 4, 2022 11:49
@Molkobain
Copy link
Contributor

Accepted during technical review.
Guillaume will created the corresponding bug in our internal bug tracker.

Remaining question for technical / functional teams: Should we add v1.4 of the API for this, if so in which iTop versions.

@Molkobain Molkobain changed the title Improve feedback when updating objects via REST without changes N°5370 - Improve feedback when updating objects via REST without changes Aug 2, 2022
@Molkobain
Copy link
Contributor

Hello Lars,

The functional aspect was accepted during today's review.
We are still discussing about the technical implementation as it might be a breaking change for some people interpreting the result of the call in the v1.3 of the API.

I'm checking if there are other REST/API related bugs that we could pack to this future v1.4 version of the API.

Cheers,
Guillaume

@Molkobain
Copy link
Contributor

Molkobain commented Aug 9, 2022

For now iTop doesn't handle multiple versions of it own API meaning that one cannot call API v1.2 on iTop 3.0 for example.
If we increase the version to 1.4 for this change in iTop 3.1, all existing webservices querying iTop with the v1.3 of the API will break after upgrading to iTop 3.1... This is quite ugly. 😕

We should think to a proper way to handle this better, do you have any proposition?

PS: Except for a better handling of tag attributes, there were not many requests on the REST/API enhancements

@Hipska
Copy link
Contributor

Hipska commented Aug 9, 2022

@Molkobain there is the $sVersion variable where it can do a version_compare to do the current behaviour or the new behaviour..

@Molkobain
Copy link
Contributor

Yes, what I meant is that I don't feel like adding "if / version_compare()" conditions everywhere in the ExecOperation() method each time we change something.
Even though there would be only one for now, it would eventually become a mess. That's why I would like to find a more elegant solution; do you know how other APIs manage it?

@Hipska
Copy link
Contributor

Hipska commented Aug 10, 2022

This might be useful to read:
https://stackoverflow.com/questions/29871744/how-do-you-manage-the-underlying-codebase-for-a-versioned-api

@Molkobain Molkobain removed their assignment Aug 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API enhancement New feature or request
Projects
Status: Pending contributor update
Development

Successfully merging this pull request may close these issues.

4 participants