Views: 4823
Last Modified: 14.08.2020
|
Bitrix24 exists both as Cloud-based service and Self-hosted editions installed at client's side. |
The advantage of REST applications is that they can operate in both versions equally effectively. Especially when required application specifics are anticipated within development beforehand.
Bitrix24 Cloud always has access to the "latest REST version". Edition updates are released after some time after they appear in Cloud version, because Bitrix24 Self-hosted contains additional features and requires more time for compatibility testing.
Additionally, there is no guarantees that owner of a specific Bitrix24 Self-hosted edition didn't install the latest available updates and generally installed Bitrix24 modules needed for the developed application to operate correctly (for example no one can restrict Bitrix24 Self-hosted user to disable telephony module completely). It means that there is no certainty that specific REST methods are available when installing an application.
That's why Recommendation No. 1 - check list of available methods and events in your solution's installation script. Execute the methods methods and events and inform user that he/she must install updates to Bitrix24
|
Bitrix24 authentication server |
When you application renews authentication tokens with refresh_token, there are two available options: get new pair tokens by requesting
xxx.bitrix24.xxx/oauth/token/?
grant_type=authorization_code... or
by requesting the authentication server oauth.bitrix.info/oauth/token/?
grant_type=authorization_code...
In case of Bitrix24 Cloud, both options are equally useful, because Bitrix24 Cloud will simply forward your query to the actual authentication server. However, Bitrix24 Self-hosted may not do this.
That's why Recommendation No. 2 - always only directly query the authentication server for token updates. This will work for both Cloud and Self-hosted editions.
By requesting REST methods, your application executes request to a specific Bitrix24. However, your app receives REST events in any case not directly from such specific Bitrix24, but via event queue, which is located in cloud, even in case of Bitrix24 Self-hosted.
A situation is possible, when owner of Bitrix24 Self-hosted for some reasons has closed network access to event queue server. In this case, events won't be working. If you are in progress of implementing a solution, you need to recommend to whitelist the event queue server when communicating with client.
The same applies to authentication server. When network access is closed to it, REST won't be operational in Bitrix24 Self-hosted, because Bitrix24 Self-hosted won't be able to validate token used by your application.