Код по запросу: технология отправки исполняемого кода с сервера на клиент. Java, ActionScript, JavaScript – примеры. Выполнение на стороне пользователя.
Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
В распределенных вычислениях, код по запросу – это любая технология, которая отправляет исполняемый программный код с сервера на компьютер клиента по запросу программного обеспечения клиента. Некоторые известные примеры парадигмы кода по запросу в сети – это Java-апплеты, язык ActionScript от Adobe для Flash Player и JavaScript. Программный код находится в неактивном состоянии на веб-сервере до тех пор, пока пользователь (клиент) не запросит веб-страницу, содержащую ссылку на этот код, с помощью веб-браузера. По этому запросу веб-страница и программа передаются на компьютер пользователя по протоколу HTTP. Когда страница отображается, код запускается в браузере и выполняется локально, на компьютере пользователя, до тех пор, пока не будет остановлен (например, при закрытии пользователем веб-страницы). Код по запросу является частным случаем мобильного кода в области перемещения кода.
In distributed computing, code on demand is any technology that sends executable software code from a server computer to a client computer upon request from the client's software. Some well known examples of the code on demand paradigm on the web are Java applets, Adobe's ActionScript language for the Flash Player, and JavaScript. The program code lies inactive on a web server until a user (client) requests a web page that contains a link to the code using the client's web browser. Upon this request, the web page and the program are transported to the user's machine using HTTP. When the page is displayed, the code is started in the browser and executes locally, inside the user's computer until it is stopped (e. g., by the user leaving the web page). Code on demand is a specific use of mobile code, within the field of code mobility.
Клиент-сервер
Первое ограничение заключается в том, что система должна состоять из клиентов и серверов. Серверы обладают ресурсами, которые необходимы клиентам. Например, сервер хранит список цен на акции (то есть является ресурсом), а клиент хотел бы отобразить эти цены в виде наглядных графиков. Между ними существует четкое разделение ответственности. Сервер отвечает за серверную часть (хранение данных, бизнес-логику и т.п.), а клиент – за клиентскую часть (пользовательский интерфейс).
The first constraint is that the system must be made up of clients and servers. Servers have resources that clients want to use. For example, a server has a list of stock prices (i. e. a resource) and the client would like to display these prices in some nice graphs. There is a clear separation of concerns between the two. The server takes care of the back end stuff (data storage, business rules, etc.) and the client handles the front end stuff (user interfaces).
Без гражданства
Для дальнейшего упрощения взаимодействия между клиентами и серверами, второе ограничение заключается в том, что общение между ними должно быть без состояния. Это означает, что вся информация о сессии клиента хранится на стороне клиента, и сервер полностью не сохраняет никакой информации о ней. Как следствие, каждый запрос должен содержать всю необходимую информацию для его обработки (то есть не может полагаться на какую-либо контекстную информацию).
To further simplify interactions between clients and servers, the second constraint is that the communication between them must be stateless. This means that all information about the client’s session is kept on the client, and the server is completely unaware. The consequence is that each request must contain all information necessary to perform the request (i. e. it cannot rely on any context information).
Кэш-память
Последнее ограничение взаимодействия клиент-серверной архитектуры заключается в том, что ответы серверов должны помечаться как кэшируемые или не кэшируемые. Эффективная кэш-память может сократить число взаимодействий между клиентом и сервером, что положительно сказывается на производительности системы. По крайней мере, с точки зрения пользователя.
The last constraint on the client server communication is that responses from servers must be marked as cacheable or non cacheable. An effective cache can reduce the number of client server interactions, which contributes positively to the performance of the system. At least, from a user’s point of view.
Код по запросу
Код по запросу (COD) — единственное необязательное ограничение в REST. Он позволяет клиентам повысить свою гибкость, поскольку сервер определяет, как будут реализованы определенные функции. Например, с помощью кода по запросу клиент может загрузить Javascript, Java-апплет или даже Flash-приложение для шифрования обмена данными, чтобы серверы не имели доступа к используемым в этом процессе алгоритмам и ключам шифрования. Однако использование COD снижает прозрачность, поэтому это ограничение является необязательным. К тому же, не всем API требуется подобная гибкость.
Code on demand (COD) is the only optional constraint in REST. It allows clients to improve their flexibility because it is the server who decides how certain things will be done. For instance, with code on demand, a client can download a Javascript, Java applet or even a Flash application in order to encrypt communication so servers are not aware of any encryption routines / keys used in this process. However, using COD reduces visibility, which is why this constraint is optional. Also, not every API needs this kind of flexibility.