Ah, yeah, after looking through the REST calls, all of what I was asking already seem to be there.

You can already do:

HEAD (or GET) /requisitions/{name}

...and it will write it to disk. It's only in-memory until a read operation occurs. (This is to speed up the not-uncommon usage of pushing a bunch of nodes to a requisition, then doing something with it, previously it would re-read the whole file and re-write it every time you made a change.)

...and for importing, you can always use send-event to import a URL directly, it will get written to the etc/imports/ when the import completes.

To revert the pending changes to the current, you should already be able to make a DELETE HTTP call to /requisitions/{name}/pending. If you mean to revert the in-memory to the version in pending on-disk, well... You could POST the entire contents of the on-disk one to /requisitions/{name} to replace it, I believe.

Could we add additional URLs to work with in-memory copy of the pending data?

/requisitions/{name}/pending/export
export in-memory copy of pending data to disk ($OPENNMS_HOME/etc/imports/pending/{name}.xml)

/requisitions/{name}/pending/import
Replaces the existing in-memory copy of pending data with the contents of the on disk file ($OPENNMS_HOME/etc/imports/pending/{name}.xml).

/requisitions/{name}/pending/delete
Reverts the pending changes to the current deployed version of the the requisition.

Then if someone wanted to make changes via both URL calls and on disk, they have the means to get the two into sync.

Using the ReST API directly is cool too, the problem is when you mix and match using the ReST API and the filesystem. It is correct to do either everything through ReST, or nothing, but not both.

So the behavior is fine, it's just provision.pl that needs to consider a redirect as success (since on success we redirect to the appropriate get for the data just submitted). It is not correct to assume you can make a bunch of ReST put calls and then expect to see the changes in $OPENNMS_HOME/etc/imports/pending without performing an import or synchronous call first.

Not saying you're doing that or anything wrong necessarily, just clarifying a point in how the ReST stuff is expected to work from our PoV. The etc/imports/ dir is an implementation detail, and really not meant to be interacted with directly even though in practice many people do.

I just want to let you know that I re-fixed https://opennms.atlassian.net/browse/NMS-6072#icft=NMS-6072. Now provision.pl is completely in sync with the new asynchronous operation. So now, the file will be created on the pending directory only if an explicit GET request is performed.