|
Mit rss feeds
|
| bet | 7/7 | | Sana | 15.03.2017 | | Hajmi | 35,17 Kb. | | #55 |
Options
Id_translation
The adapter has one optional control, id_translation. This option is useful when the external system submits REST URLs that contain an alternate identifier instead of an Aleph id. With id_translation set on (the default), the adapter extracts the incoming alternate identifier from the URL, calls the X-server to get the corresponding Aleph id, and substitutes the Aleph id for the alternate identifier in the call to the REST API. If this conversion of identifiers is not needed, id_translation can be turned off.
If a remote server needs to call the REST API with an alternate identifier, one of three scenarios must be followed.
-
The adapter is not installed.
In this case, the remote server must first call the X-server’s ‘bor-by-key’ function, passing the alternate identifier and receiving the corresponding Aleph id. The Aleph id can then be interpolated into subsequent calls to the REST API.
-
The adapter is installed, but id_translation is turned off.
This case requires the same process as case #1.
-
The adapter is installed and id_translation is turned on (default)
In this case the remote server calls the adapter with a REST URL containing an alternate identifier. The adapter extracts the alternate identifier, calls the X-server to retrieve the corresponding Aleph id, replaces the alternate identifier in the URL with the Aleph id, and sends the enhanced URL on to the REST API. Since the X-server call in this case is done on the local server without going out on the network it is very fast
Under what circumstances should id_translation be turned off?
If the remote server is populating all its REST URLs with Aleph ids, then the translation step is wasted processing time. In that case, id_translation can be turned off with these actions:
-
Make a backup copy of api_adapter.cgi.
-
Edit api_adapter.cgi
-
Find this text ‘my $id_translation = 1;’ and change the 1 to a zero.
-
Save the file.
|
| |
