Set Scope during REST Api Create Domain Call

Developers

Hello Data Citizen Community,

does someone know if it is possible to set the scope of a domain when creating it with a rest api call?

Sincerely,
Stefan

stefan_busch

Posted 4 years ago · Edited 2 years ago·Last reply 2 years ago

11 comments

nikhiladla

·2 years ago · Edited

Does anyone know if this bug has been fixed?

stefan_busch

OP3 years ago · Edited

@arthur.burkhardt
fyi
I did report the bug and got now a confirmation that they work on a fix. The fix is scheduled for the next major version. The behaviour of the rest call after the fix will be like suggested from you.
Cheers

stefan_busch

OP4 years ago · Edited

Hello,
So i played a bit around with the patch request and got some interesting behaviour. Let’s say I have 2 domain ids. Id_1 is within in the scope and id_2 is currently not in the scope.
Now I want to add id_2 to the scope. If I use the patch call and only specify the id_2 it will remove id_1 from the scope and add id_2 to it. If I call patch with both id_1 and id_2 there will only be id_2 in the scope after the call (id_1 gets removed).
So no matter what I try it will always remove id_1 from the scope. The only way around this is by first getting all domains within scope 1 ( id_1 in this scenario), then calling patch with all current domain ids ( id_1), thereby removing domain 1 from the scope. After that calling patch again but this time with all ids (id_1 and id_2).
This seems not really like the intended behavior. If I call patch with both ids it should not remove the already existing id from the scope in my opinion.

arthurburkhardt

·4 years ago · Edited

Hahahhaha, that’s hilarious. I thought you must have done something wrong, but no sir, I second your opinion there is a bug. Will you open a support ticket?

Quick recap, I hope it’s correct.

Initial situation	Patch	Result
null	domainA	domainA
null	domainB	domainB
null	domainA, domainB	domainA, domainB
domainA	domainA	null
domainB	domainB	null
domainA	domainB	domainB
domainB	domainA	domainA
domainA, domainB	domainA	null
domainA, domainB	domainB	null
domainA, domainB	domainA, domainB	null

It would also be nice to have an API call to “add domainId to scope” and “add communityId to scope”. This would remove the need for lookup then patch.

stefan_busch

OP4 years ago · Edited

Hello,
i was on holiday last week so I just saw your answer now. Did you already create a support ticket? If not I can create one, your testing will come in handy.

stefan_busch

OP4 years ago · Edited

Hi,
i have one more comment regarding your table. In my opinion row 4, 5 and 10 should be a success and row 6 and 7 should not be a success. My reasoning would be that for every entry in the patch call i would be like flipping a switch, so if an entry was already active before the patch call it would be disabled afterwards and if it was not active before the patch call i would be enabled. This would may be a more fitting definition for a PATCH call and would allow us to enable and disable domains. In my opinion the correct result for row 6 and 7 should be that domainA and domainB are both active. But i would like to hear your opinion about it.

arthurburkhardt

·4 years ago · Edited

I have not opened a ticket support yet, so feel free to do so.
AFAIK, patch overwrites the properties of an entity. So, regardless of the existing state of the assignment, it should set the collection of associated resources (domains, communities…) to whatever is mentioned in the payload. It should not work as a toggle switch, otherwise you violate the principle of idempotence.

But we might consider additional endpoints, for example to “add a resource to a scope” or “remove a resource from a scope”.

stefan_busch

OP4 years ago · Edited

I think PATCH does not have to be idempotent, at least that it was the mozilla developer page is saying (https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/PATCH), but in this case i would look at the other PATCH calls Collibra has to offer and would try to mimic their behaviour (if they’re idempotent then i would agree that this call should be too otherwise it don’t has to imo)

arthurburkhardt

·4 years ago · Edited

stefan.busch:

PATCH does not have to be idempotent

Ahaha, you caught me there, you’re right. I wonder when it is justifiably non-idempotent. I can see examples of incrementing a counter for example, but I would think that using it as a switch is dubious.
It would be a dubious behavior for the endpoint to toggle domains on and off with the same payload.

stefan_busch

OP4 years ago · Edited

Fair point, then i will write a bug report with your proposal for the behaviour.

arthurburkhardt

·4 years ago · Edited

Yes, @stefan.busch you can patch the scope to add whichever domains you want.