# Method Based Services
This is a sample extracted from a [Delphi Praxis Forum page](https://www.delphipraxis.net/210980-mormot-einfuehrung-methodenbasierte-services-server-und-client.html).
With the example code you get:
- An HTTP server for HTTP/1.0/1.1 requests.
- Authentication of the user on the server and creation of a user-specific directory.
- Login with the client to the server and exchange content list and image documents.
- Connection of a progress indicator with the help of a mediator.
- Acceleration in saving and reading graphic formats JPEG, PNG, GIF, TIFF.
- And some little things more...
The interface is kept very simple and includes only a few functions. The source code is written in such a way that it invites you to try it out on your own.
## Source code
The Source code has been extracted from the original `.zip` attached with the article.
But a `TestImage.png` picture is expected to be available in the executable folder, for testing the PNG reading/writing.
# Translated Documentation
Just copy and pasted from Google Translator, with a quick manual review and formatting.
## Presentation
The third article in the mORMot introduction series deals for the first time with the area for which the library was created.
Arnaud Bouchez describes his work as a client-server ORM/SOA framework and writes: " The Synopse mORMot framework implements a Client-Server RESTful architecture, trying to follow some MVC, N-Tier, ORM, SOA best-practice patterns ".
The implementation happens on the principles of these architecture principles . If the terms SOA and RESTful architecture do not mean much to you, you can read about them at the following links:
Wikipedia: [Service-Oriented Architecture](https://en.wikipedia.org/wiki/Service-oriented_architecture) , mORMot Help: [Service-Oriented Architecture](https://synopse.info/files/html/Synopse%20mORMot%20Framework%20SAD%201.18.html#TITL_17)
Wikipedia: [Representational State Transfer](https://en.wikipedia.org/wiki/Representational_state_transfer) , mORMot Help: [Representational state transfer](https://synopse.info/files/html/Synopse%20mORMot%20Framework%20SAD%201.18.html#TITL_9)
The sample application server and client is intended to present as much functionality as possible with just a few lines of source code. This is about concepts, not about a finished copy-paste solution. The contained references to the documentation link to the currently available mORMot1 help. mORMot2 is used for the example . Class and function names may differ slightly.
Attached is the source code and the executable program for server and client. Disclaimer: The source code is neither tested nor optimized. It should work with Delphi 10.2 or later. The use of the materials provided is at your own risk. And even worse today: Anyone who makes the example server accessible on the Internet despite all the warnings should write the following sentence 1000 times as a punishment: "I will never again use a program in an area for which it was not intended!". I personally supervise the implementation.
Based on the first two example applications, images are also managed here. The server stores the images in the user's own directory (each user has their own directory). With the example source code for the server and client you get:
- An HTTP server for HTTP/1.0/1.1 requests.
- Authentication of the user on the server and creation of a separate directory.
- Registration with the client on the server and exchange of content list and image documents.
- Connection of a progress display with the help of a mediator.
- Accelerated saving and reading of the graphic formats JPEG, PNG, GIF, TIFF.
## Basic prior knowledge
The following points are only touched upon briefly. Each individual would warrant a separate treatise. They are important for understanding the example application.
### 1) REST Server
The RestServer inherits REST functionality from the `TRestServer` class and its descendants. Any number of RestServers, each with their own model, can be operated in one program. However, each model must have a unique root name. In a shop application, for example, it makes sense to distribute the administration and shop areas with their respective functions to specialized RestServers. If the RestServer "Shop" is registered under the root name `Shop`, a service function `ArticleBuy` is called via the root `Shop/ArticleBuy` . A full URI might look like this:
```
https://www.domain.de/Shop/ArticleBuy?ArticleID=123&AccessToken=xyz
```
These descendants of the `TRestServer` class are currently available in mORMot:
- `TRestServerFullMemory` - The ideal gateway to the outside world. This lightweight class implements a fast in-memory engine with basic CRUD functions for the ORM. It is entirely sufficient to handle authentication and host services in a standalone manner. Functionality that is not available is also not a target for attack.
- `TRestServerDB` - This class is the most important of its kind and hosts a SQLite engine as the central database layer. Your possibilities were already shown in the first article of the series.
### 2) Connection protocol
The RestServer can be addressed stand-alone, i.e. directly via its methods, or in a client-server model via the communication layer HTTP/1.0/1.1 via TCP/IP . The possibilities depend on the protocol used. For a client-server application is generally used, let's ignore special cases such as `WebSockets`, on the server the class `TRestHttpServer` and on the client the class `TRestHttpClientUri` or descendants. There are different server modes when instantiating the `TRestHttpServer` class to select:
- `useHttpApi###` - Uses the kernel-mode http.sys server available since Windows XP SP3.
- `useHttpAsync` - A socket based server in event-driven mode with a thread pool. Therefore, it scales very well over many connections, especially keep-alive connections.
- `useHttpSocket` - A socket based server with one thread per active connection using a thread pool. This type is better used behind a reverse proxy server in HTTP/1.0 mode.
The classes `TRestHttpClientSocket`, `TRestHttpClientWinINet` and `TRestHttpClientWinHttp` are available for the client on Windows. In the example we use `WinHttp` to implement a progress display with the help of a mediator.
### 3) Authentication
The authentication classes present in mORMot are : `TRestServerAuthenticationNone`, `TRestServerAuthenticationDefault`, `TRestServerAuthenticationHttpBasic` and `TRestServerAuthenticationSsp`i. As an alternative, the use of JWT (JSON Web Tokens) is possible. In the example, mORMot's own proprietary solution is used. It is implemented in the `TRestServerAuthenticationDefault` class. In the sample server, logging is enabled. The ping/pong between client and server to establish a session can be tracked in the printout. The procedure is a good compromise between security and speed.
Even if authentication is enabled, individual methods can be exempted by calling the RestServer function `ServiceMethodByPassAuthentication('MethodName')`. One of the default service method, freely accessible functions is `Timestamp`. To test on the sample server, enter the following call in the browser:
```
http:// localhost :8080/Files/Timestamp
```
After execution, a multi-digit number, the timestamp of the server, is displayed in the browser window.
## Accelerated saving and reading of images
The last item in the list has already been discussed in the previous article. It is only mentioned again to complement it.
## Your own RestServer
In mORMot, there are two types of services:
- Method-based Services, mORMot help: [Client-Server services via methods](https://synopse.info/files/html/Synopse%20mORMot%20Framework%20SAD%201.18.html#TITL_49)
- Interface-based Services, mORMot help: [Client-Server services via interfaces](https://synopse.info/file