The concept of the universal API was introduced in the chapter Universal API for Access to D2000. Before we will describe individual REST and Comet API interfaces, it is necessary, in the following chapter, to describe a way of serializing values and parameters which is similar in both interfaces.
Usability of Individual API Interfaces
To answer the question of why SmartWeb implements two and not just one API interface, we need to look at the appropriateness of individual interfaces used in various situations.
D2000 is a real-time SCADA system that is able to record changes of a high number of, for example, I/O tags. In order for a web or other application to be notified about these changes, it is necessary to implement a communication technology of the server-push type in which a server alone notifies the client about the change of the object value. Otherwise, it is necessary for the client to periodically ask a server in some time interval whether there were any changes in observed objects. This communication method is, however, very inconvenient. When having a longer time interval, a situation may arise that the object value will change right after the server's answer and the client will not be informed about this value until checking the server again. On the other hand, if the time interval is too short and the value is changing sporadically, considerable wasting of communication means may happen unnecessarily. Because of this, there are situations when we really use a communication technology that supports the server-push. However, the server-push way of communicating is not standardized that is why we needed to choose one existing and available technology. Ideally such communication that would support robust server-push communication between a web application in the browser and a server. After analysing all options, we chose technology based on the Comet communication concept implemented in the robust JAVA library Cometd with long production history and with the use in a cloud solution with more than 150 000 clients.
SmartWeb implements the Comet communication concept mostly for acquiring current values and the possibility to call from D2000 also remote RPC methods registered and performed on a client. Since these usage cases are not always required for the application, it is possible to use easy-implementation and standardized REST API interface that is a subset of the Comet API.
Authentication in Individual API Interfaces
As we have already mentioned in the chapter Other Functions of the SmartWeb Platform, the authentication way of individual interfaces differs. The REST API with its HTTP-BASIC authentication is more aimed at communication for non-web clients, the Comet API will redirect the unidentified user to the login form (FORM authentication) and that is why this interface is currently naturally suitable for communication between web applications and servers.
Info |
---|
In a case of need, also another client can communicate as a web application via the Comet API. The only condition is for the client to be able to authenticate by sending a special HTTP requirement emulating login through a login form. The alternative, however a more complicated possibility, is to directly show the login form to a user in a special window with an embedded browser and after a successful login, extract authentication cookie for another use in the |
Koncept univerzálneho API bol predstavený v kapitole Univerzálne API pre prístup do D2000. Skôr než budú popísané jednotlivé rozhrania REST a Comet API je potrebné v nasledujúcej kapitole popísať spôsob serializácie hodnôt a parametrov, ktorý je pri oboch rozhraniach totožný.
Použiteľnosť jednotlivých API rozhraní
Na otázku prečo SmartWeb implementuje dve a nie iba jedno API rozhranie, treba hľadať odpoveď vo vhodnosti použitia jednotlivých API pre rôzne situácie.
D2000 je realtime SCADA systém, ktorý je schopný zaznamenávať zmeny veľkého počtu napr. meraných bodov. Na to aby o týchto zmenách bola notifikovaná aj webová, prípadne iná aplikácia, je potrebné implementovať komunikačnú technológiu typu server-push, kedy server sám notifikuje klienta o zmene hodnoty objektu. V opačnom prípade je nevyhnutné, aby sa klient periodicky v nejakom časovom intervale pýtal servera či nenastali zmeny hodnôt ním sledovaných objektov. Tento spôsob komunikácie je ale veľmi nevýhodný. Pri dlhšom časovom intervale môže nastať situácia, že hodnota objektu sa zmení tesne po odpovedi servera a klient nie je informovaný o tejto hodnote, až kým znova neskontroluje server. Na druhej strane ak je časový interval príliš krátky a hodnota sa mení sporadicky, môže dochádzať úplne zbytočne k značnému plytvaniu komunikačných prostriedkov. Z týchto dôvodov sú situácie kedy komunikačnú technológiu podporujúcu server-push naozaj využijeme. Spôsob server–push komunikácie ale nie je štandardizovaný, a preto bolo potrebné vybrať jednu z existujúcich technológií, ktoré boli k dispozícii. Ideálne takú ktorá bude podporovať robusnú server-push komunikáciu medzi webovou aplikáciou v prehliadači a serverom. Po analýze možností bola vybraná technológia postavená na komunikačnom koncepte Comet implementovanom v robusnej java knižnici Cometd, s dlhou produkčnou históriou a použitím v cloudovom riešení s viac ako 150 000 klientmi.
SmartWeb implementuje komunikačný koncept Comet predovšetkým kvôli získavaniu aktuálnych hodnôt a možnosti volať z D2000 aj vzdialené RPC metódy zaregistrované a vykonávané na klientovi. Keďže tieto prípady použitia nie sú vždy pre aplikáciu požadované, je možné použiť implementačne jednoduchšie a štandardizované rozhranie REST API, ktoré je podmnožinou Comet API.
Autentifikácia v jednotlivých API rozhraniach
Ako už bolo spomenuté v kapitole Ďalšie funkcie SmartWeb platformy, spôsob autentifikácie jednotlivých rozhraní je rozdielny. REST API so svojou HTTP-BASIC autentifikáciou je skôr určené na komunikáciu pre ne-webových klientov, Comet API neautentifikovaného používateľa presmeruje na prihlasovací formulár (FORM autentifikácia) a preto je toto rozhranie momentálne prirodzene vhodné na komunikáciu webových aplikácii so serverom.
Info |
---|
V prípade potreby, vie cez Comet API komunikovať aj iný klient ako web aplikácia. Jedinou požiadavkou je aby bol schopný sa autentifikovať cez poslanie špeciálnej HTTP požiadavky emulujúcej prihlásenie cez prihlasovací formulár. Alternatívnou ale komplikovanejšou možnosťou je zobraziť priamo prihlasovací formulár používateľovi v špeciálnom okne s vnoreným prehliadačom a po úspešnom prihlásení extrahovať autentifikačné cookie pre ďalšie použitie v Comet API. |