Other Tasks

This chapter explains basic tasks you can do with XData in code. It basically explains how to setup and start the server and how to do some basic configuration using the available classes and interfaces. The following topics describe the most common XData programming tasks and main classes and interfaces.

Creating an XData Server

TMS XData Server is based on the TMS Sparkle framework. The actual XData Server is a Sparkle server module that you add to a Sparkle HTTP Server.

Please refer to the following topics to learn more about TMS Sparkle servers:

To create the XData Server, just create and add a XData Server Module (TXDataServerModule class, declared in unit XData.Server.Module) to the Sparkle HTTP Server. The following code illustrates how to create and run the server. Note that the code that creates the XData server module is not displayed here. You should refer to the "XData Server Module" topic to learn about how to create the module.

uses
  {...}, 
  Sparkle.HttpSys.Server, XData.Server.Module;

function CreateXDataServerModule(const BaseUrl: string): TXDataServerModule;
begin
  // Create and return the TXDataServerModule here,
  // using the BaseUrl as the server address
end;

var
  Module: TXDataServerModule;
  Server: THttpSysServer;
begin
  Server := THttpSysServer.Create;
  Module := CreateXDataServerModule('http://server:2001/tms/xdata');
  Server.AddModule(Module);
  Server.Start;
  ReadLn;
  Server.Stop;
  Server.Free;
end;

The code above will create and start an XData server that will receive and respond to HTTP requests at the address "http://server:2001/tms/xdata".

TXDataServerModule

To create an XData server, you need to add a TXDataServerModule object to the Sparkle HTTP Server. As with any Sparkle module, it will have a base (root) URL associated with it, and it will respond to requests sent to any URL which matches the root URL of the module.

The TXDataServerModule is the main XData class, because it is the one which receives and handles all HTTP requests. So in a way, that is the class that implements the XData server. Although it is a very important class, its usage is very simple. You need to create the class using one of the overloaded constructors (TXDataServerModule is declared in unit XData.Server.Module):

constructor Create(const ABaseUrl: string); overload;
constructor Create(const ABaseUrl: string; AConnectionPool: IDBConnectionPool); overload;
constructor Create(const ABaseUrl: string; AConnectionPool: IDBConnectionPool;
  AModel: TXDataAureliusModel); overload;
constructor Create(const ABaseUrl: string; AConnection: IDBConnection); overload;
constructor Create(const ABaseUrl: string; AConnection: IDBConnection;
  AModel: TXDataAureliusModel); overload;

In summary, you must provide the base URL and optionally an IDBConnectionPool interface so that the server can retrieve IDBConnection interfaces to operate with the database (if database connectivity is desired). For example:

XDataServerModule := TXDataServerModule.Create('http://server:2001/tms/xdata',
  TDBConnectionPool.Create(50,
    TDBConnectionFactory.Create(
      function: IDBConnection
      var
        MyDataModule: TMyDataModule;
      begin
        MyDataModule := TMyDataModule.Create(nil);
        Result := TFireDacConnectionAdapter.Create(MyDataModule.FDConnection1, MyDataModule);
      end
)));

The example above creates the server with the root URL "http://server:2001/tms/xdata" providing a connection pool of a maximum of 50 simultaneous connections. The database connection used will be a FireDac TFDConnection component named FDConnection1, declared in a data module named TMyDataModule. That is all you need to set up for your XData server to run and to expose your Aurelius objects.

The first overloaded constructor, used in the previous example, takes just two parameters: the base url and the connection pool. The other overloaded versions are just variations that provide different settings.

If you have multiple Aurelius mapping models in your application, you can optionally use an entity model different from default, or explicitly build an entity model and provide it in the constructor for specific mapping. This allows for better control which classes and mapping settings are available from the XData server. If the model is not provided, XData uses the default entity model which in turn uses the default Aurelius model. Note that the model passed to the constructor will not be owned by the server module and must be destroyed manually. For example, the following code creates a module using the "Sample" model:

XDataServerModule := TXDataServerModule.Create('http://server:2001/tms/xdata',
  MyConnectionPool, TXDataAureliusModel.Get('Sample'));

There are also versions of the Create constructor that receive an IDBConnection interface instead of an IDBConnectionPool. Those are easy-to-use variations that internally create a connection pool with a single connection (no simultaneous connections available). It is an easy approach for testing and debug purposes, but should not be used in production environments because performance might not be ideal.

Properties

Name Description
UserName: string
Password: string		 TXDataServerModule provides these properties to specify UserName and Password required by the server using Basic Authentication. By default, these values are empty which means no authentication is performed and any client can access server resources and operations. When basic authentication is used, be sure to use HTTP secure (HTTPS) if you do not want your user name or password to be retrieved by middle-man attacks. If you do not use it, both user name and password are transmitted in plain text in HTTP requests.

These properties provide a very limited basic authentication mechanism. For a more advanced variant, you should use the TMS Sparkle built-in Basic Authentication mechanism.
AccessControlAllowOrigin: string Specifies the accepted client hosts for which CORS will be enabled. If you want to accept any client connection, set this property value to '*'. This will enable CORS in the server including proper responses to preflighted requests.
DefaultExpandLevel: integer Defines the minimum level that associated entities will be expanded (included inline) in JSON responses. Default value is 0 meaning that all associated entities will be represented as references unless specified otherwise. Clients can override this value by using xdata-expand-level header.
Events: TXDataModuleEvents Container for server-side events.
PutMode: TXDataPutMode Defines how PUT will be implemented at server side with Aurelius: Either TXDataPutMode.Update or TXDataPutMode.Merge method (default). You will rarely need to change this property unless to ensure backward compatibility with older versions. This property value can be overridden in a specific request by using xdata-put-mode HTTP Request header.
SerializeInstanceRef: TInstanceRefSerialization Controls how instance reference ($ref) will appear in JSON response. See below for options.

This property value can be overridden in a specific request by using xdata-serialize-instance-ref HTTP Request header.
SerializeInstanceType: TInstanceTypeSerialization Controls whenever the entity/object type appears in the JSON response (property annotation "xdata.type"). See below for options.

This property value can be overridden in a specific request by using xdata-serialize-instance-type HTTP Request header.
UnknownMemberHandling: TUnknownMemberHandling Defines server behavior when receiving JSON from the client with a property that is not known for that request. For example, JSON representing an entity with a property that does not belong to that entity. See below for options.
RoutingPrecedence: TRoutingPrecedence Specifies which route to use when there is a conflict between URL endpoints defined by automatic CRUD endpoints and service operations . See below for options.
EnableEntityKeyAsSegment: Boolean When True, it's possible to address single entities by using the URL format "/entityset/id" - in addition to the default "/entityset(id)". Default is False.
SwaggerOptions: TSwaggerOptions
SwaggerUIOptions: TSwaggerUIOptions		 Provide access to configure Swagger and SwaggerUI behavior. See more information at OpenAPI/Swagger Support.

TInstanceRefSerialization

  • TInstanceRefSerialization.Always: $ref is always used if the same instance appears again in the JSON tree. This mode is more optimized for use with TXDataClient, and is the default option.

  • TInstanceRefSerialization.IfRecursive: $ref is only used if the instance appears as an associated object of itself. If the instance appears in a non-recursive way, $ref is not used and the instance is fully serialized inline instead. This mode is more suited for JavaScript and other non-Delphi clients so those clients do not need to resolve the $ref objects.

TInstanceTypeSerialization

  • TInstanceTypeSerialization.Always: The xdata.type annotation always appears in JSON responses.

  • TInstanceTypeSerialization.IfNeeded: The xdata.type annotation is only present if the entity/object type is a descendant of the expected type. For example, suppose a GET request is performed in url Customers. For any entity in JSON that is of type Customer, the annotation will not present. If the entity in JSON is a descendant of Customer (e.g., DerivedCustomer) then xdata.type apppears. Basically, it means that xdata.type is implicit when absent and is of the expected type of the request/specification.

TUnknownMemberHandling

  • TUnknownMemberHandling.Error: An InvalidJsonProperty error is raised if JSON contains an invalid property. This is the default behavior.

  • TUnknownMemberHandling.Ignore: Invalid properties in JSON will be ignored and the request will be processed.

TRoutingPrecedence

  • TRoutingPrecedence.Crud: The URL from automatic CRUD endpoint will be used if there is a URL conflict with service operation endpoints. This is the default behavior.

  • TRoutingPrecedence.Service: The URL from service operation will be used if there is a URL conflict with automatic CRUD endpoints.

Methods

Name Description
procedure SetEntitySetPermissions(const EntitySetName: string; Permissions: TEntitySetPermissions) Specify the permissions for a specified entity set.

IDBConnectionPool Interface

The IDBConnectionPool interface is used by the XData server module to retrieve an IDBConnection interface used to connect to a database. As client requests arrive, the XData server needs an IDBConnection interface to connect to the database server and execute the SQL statements. It achieves this by trying to acquire an IDBConnection interface from the IDBConnectionPool interface. Thus, providing an IDBConnectionPool interface to the XData server module is mandatory for this to work.

The IDBConnectionPool interface is declared in the unit Aurelius.Drivers.Interfaces and contains a single GetConnection method:

IDBConnectionPool = interface
  function GetConnection: IDBConnection;
end;

The easiest way to create an IDBConnectionPool interface is by using the TDBConnectionPool class which implements the IDBConnectionPool interface. To instantiate it, you need to call the Create constructor passing an IDBConnectionFactory interface which will be used by the connection pool to create a new connection if needed. Alternatively, you can pass an anonymous method that creates and returns a new IDBConnection interface each time it is called.

Also, you need to specify the maximum number of IDBConnection interfaces (database connections) available in the pool. Whenever a client request arrives, the XData server acquires an IDBConnection from the pool, does all the database processing with it, and then returns it to the pool. If many simultaneous requests arrive, the pool might run out of available connections when the number of acquired IDBConnection interfaces reaches the maximum number specified. If that happens, the client request will wait until a new connection is available in the pool. TDBConnectionPool class is declared in the unit XData.Aurelius.ConnectionPool.

The following code illustrates how to create an IDBConnectionPool interface. It uses a function named CreateMyConnectionFactory which is not shown in this example. To learn how to create such interface, please refer to IDBConnectionFactory topic.

uses 
  {...}, Aurelius.Drivers.Interfaces, XData.Aurelius.ConnectionPool;

var
  ConnectionPool: IDBConnectionPool;
  ConnectionFactory: IDBConnectionFactory;
begin
  ConnectionFactory := CreateMyConnectionFactory; //  Creates IDBConnectionFactory
  ConnectionPool := TDBConnectionPool.Create(
    50, // maximum of 50 connections available in the pool
        // Define a number that best fits your needs
    ConnectionFactory
  );

  // Use the IDBConnectionPool interface to create the XData server module
end;

Alternatively, you can just provide an anonymous method that creates the IDBConnection instead of providing the IDBConnectionFactory interface:

uses 
  {...}, Aurelius.Drivers.Interfaces, XData.Aurelius.ConnectionPool;

var
  ConnectionPool: IDBConnectionPool;
begin
  ConnectionPool := TDBConnectionPool.Create(
    50, // maximum of 50 connections available in the pool
    function: IDBConnection
    var
      SQLConn: TSQLConnection;
    begin
      // Create the IDBConnection interface here
      // Be sure to also create a new instance of the database-access component here
      // Two different IDBConnection interfaces should not share
      // the same database-access component

      // Example using dbExpress
      SQLConn := TSQLConnection.Create(nil);
      { Define SQLConn connection settings here, the server
         to be connected, user name, password, database, etc. }
      Result := TDBExpressConnectionAdapter.Create(SQLConn, true);
    end
  ));

  // Use the IDBConnectionPool interface to create the XData server module
end;

If you do not need a pooling mechanism but just want one database connection to be created for each time someone asks for a connection from the pool, you can use the TDBConnectionFactory class. It also implements the IDBConnectionPool interface:

var
  ConnectionPool: IDBConnectionPool;
begin
  ConnectionPool := TDBConnectionFactory.Create(
      function: IDBConnection
      var
        MyDataModule: TMyDataModule;
      begin
        // Creates a datamodule which contains a 
        // TSQLConnection component that is already configured
        MyDataModule := TMyDataModule.Create(nil);

        // The second parameter makes sure the data module will be destroyed
        // when IDBConnection interface is released
        Result := TDBExpressConnectionAdapter.Create(
          MyDataModule.SQLConnection1, MyDataModule);
      end
    ));
end;

IDBConnectionFactory Interface

The IDBConnectionFactory interface is used to create an IDBConnectionPool interface used by the XData module. As client requests arrive, the XData server needs to retrieve an IDBConnection interface from the IDBConnectionPool so it can perform operations on the database. The connection pool creates a new IDBConnection by calling IDBConnectionFactory.CreateConnection method.

The IDBConnectionFactory interface is declared in unit Aurelius.Drivers.Interfaces, and it contains a single CreateConnection method:

IDBConnectionFactory = interface
  function CreateConnection: IDBConnection;
end;

The easiest way to create such an interface is using the TDBConnectionFactory class which implements the IDBConnectionFactory interface. To create a TDBConnectionFactory object, you just need to pass an anonymous method that creates and returns a new IDBConnection interface each time it is called. The TDBConnectionFactory class is declared in the unit Aurelius.Drivers.Base.

The IDBConnection interface is part of the TMS Aurelius library used by XData. You can refer to the TMS Aurelius documentation to learn how to create the IDBConnection interface.

In the following example, the factory will create an IDBConnection pointing to a Microsoft SQL Server database using a dbExpress connection. You can connect to many other database servers (Oracle, Firebird, MySQL, etc.) using many different database-access components (FireDac, dbExpress, UniDac, ADO, etc.). Please refer to Database Connectivity topic on TMS Aurelius documentation to learn about all those options. Regardless of what you use, the structure of the following code will be the same. What will change only is the content of the function: IDBConnection.

uses 
  {...}, Aurelius.Drivers.Interfaces, Aurelius.Drivers.Base,
  Aurelius.Drivers.dbExpress;

var
  ConnectionFactory: IDBConnectionFactory;
begin
  ConnectionFactory := TDBConnectionFactory.Create(
      function: IDBConnection
      var
        conn: TSQLConnection;
      begin
        // Create the IDBConnection interface here
        // Be sure to also create a new instance of the database-access component here
        // Two different IDBConnection interfaces should not share
        // the same database-access component

        // Example using dbExpress
        conn := TSQLConnection.Create(nil);
        conn.DriverName := 'MSSQL';
        conn.GetDriverFunc := 'getSQLDriverMSSQL';
        conn.VendorLib := 'sqlncli10.dll';
        conn.LibraryName := 'dbxmss.dll';
        conn.Params.Values['HostName'] := 'server';
        conn.Params.Values['Database'] := 'master';
        conn.Params.Values['User_Name'] := 'sa';
        conn.Params.Values['Password'] := 'password';
        conn.LoginPrompt := false;
        Result := TDBExpressConnectionAdapter.Create(SQLConn, true);
      end
    ));

  // Use the ConnectionFactory interface to create an IDBConnectionPool interface
end;

It is possible that you already have your database-access component configured in a TDataModule and you do not want to create it in code. In this case, you can just create a new instance of the data module and return the associated IDBConnection to the component. But you must be sure to destroy the data module as well (not only the database-access component) to avoid memory leaks:

var
  ConnectionFactory: IDBConnectionFactory;
begin
  ConnectionFactory := TDBConnectionFactory.Create(
      function: IDBConnection
      var
        MyDataModule: TMyDataModule;
      begin
        // Creates a datamodule which contains a 
        // TSQLConnection component that is already configured
        MyDataModule := TMyDataModule.Create(nil);

        // The second parameter makes sure the data module will be destroyed
        // when IDBConnection interface is released
        Result := TDBExpressConnectionAdapter.Create(
          MyDataModule.SQLConnection1, MyDataModule);
      end
    ));

  // Use the ConnectionFactory interface to create an IDBConnectionPool interface
end;

OpenAPI/Swagger Support

The XData server can optionally provide a JSON file containing the OpenAPI Specification (OAS, formerly Swagger) for your whole server API. This opens up a lot of possibilities; usage of several tools of the OpenAPI ecosystem is possible. The main one is Swagger UI: it is web front-end to describe and test your API.

Enabling support for OpenAPI (Swagger)

To enable OpenAPI support in your server, just set the property SwaggerOptions.Enabled to true in your TXDataServer component, either in object inspector or from code:

XDataServer1.SwaggerOptions.Enabled := True;

Alternatively, if you are using TXDataServerModule instead, you can just use the unit XData.OpenAPI.Service and call the method RegisterOpenAPIService anywhere in your server application:

uses {...}, XData.OpenAPI.Service;

{...}
  RegisterOpenAPIService;

Retrieving the OpenAPI Specification (OAS) file

The OAS file is available through a GET request to the URL "/openapi/swagger.json" relative to your server root URL. For example, if your server root is http://server:2001/tms/xdata/, then you will be able to access the file from this URL:

GET http://server:2001/tms/xdata/openapi/swagger.json

Excluding methods from Swagger

You can flag some service contract methods to be excluded from Swagger document, by simply adding the [SwaggerExclude] attribute to the method:

[ServiceContract]
[Route('arith')]
IArithmeticService = interface(IInvokable)
  ['{9E343ABD-D97C-4411-86BF-AD2E13BE71F3}']
  [HttpGet] function Add(A, B: Double): Double;
  [HttpGet] function Subtract(A, B: Double): Double;
  [SwaggerExclude]
  [HttpGet] function NotThisFunctionPlease: Integer;
end;

In the example above, methods Add and Subtract will be added to the documentation, but method NotThisFunctionPlease will not appear.

Enabling Swagger UI

XData server can optionally publish and endpoint to provide a SwaggerUI web-based interface that works as both a full documentation of your API as well a test interface. Swagger UI is a web-based front-end to dynamically document and test your API. Quoting their website:

"Swagger UI allows anyone - be it your development team or your end consumers - to visualize and interact with the API's resources without having any of the implementation logic in place. It's automatically generated from your Swagger specification, with the visual documentation making it easy for back end implementation and client side consumption."

To enable SwaggerUI support in your server, just set the property SwaggerUIOptions.Enabled to true in your TXDataServer component, either in object inspector or from code:

XDataServer1.SwaggerUIOptions.Enabled := True;

Alternatively, if you are using TXDataServerModule instead, you can just use the unit XData.SwaggeUI.Service and call the method RegisterSwaggerUIService anywhere in your server application:

uses {...}, XData.SwaggerUI.Service;

{...}
  RegisterSwaggerUIService;

Using SwaggerUI

Once enabled, SwaggerUI is available in the address "/swaggerui" relative to your server base path. Just open your browser and go to the address:

http://server:2001/tms/xdata/swaggerui

It will display an interface like this:

swaggerui

Configuring Swagger (OpenAPI Specification)

For the Swagger specification, you can use SwaggerOptions property of either TXDataServer or TXDataServerModule to configure the specification returned by the server:

XDataModule.SwaggerOptions.AuthMode := TSwaggerAuthMode.Jwt;

Only available property is AuthMode and options are TSwaggerAuthMode.Jwt or None. When Jwt is enabled, a new security definition named jwt requiring an Authorization header will be added to all requests.

You can also configure the specification by passing parameters in the query part of the URL, and they can be one of the following:

Name Description
ExcludeEntities Boolean parameter. Default is False. When True, the specification will not contain the automatic CRUD operations on entities provided automatically by XData (entity resources).

Example: /openapi/swagger.json?ExcludeEntities=True
ExcludeOperations Boolean parameter. Default is False. When True, the specification will not contain any service operations.

Example: /openapi/swagger.json?ExcludeOperations=True
AuthMode String parameter. Options are "none" and "jwt". When jwt is specified, a new security definition named jwt requiring an Authorization header will be added to all requests.

Example: /openapi/swagger.json?authmode=jwt

Configuring SwaggerUI

The SwaggerUI interface can also be configured using the SwaggerUIOptions property of either TXDataServer or TXDataServerModule. Available properties are:

Name Description
ShowFilter Boolean parameter. Default is False. When True, the SwaggerUI will display a filter edit box to search for API operations.
DocExpansion Enumerated parameter. Specifies the default expand level of the listed API operations.
Valid values are: TSwaggerUIExpansion = (List, None, Full)
Default value is List.

Examples:

XDataModule.SwaggerUIOptions.Filter := True;
XDataModule.SwaggerUIOptions.DocExpansion := TSwaggerUIExpansion.None;

Using XML Documentation with Swagger

A good (if not the best) way to document your source code is to use XML Documentation Comments. In the interfaces and methods that build your service contract, you can simply add specific XML tags and content, like this:

/// <summary>
///   Retrieves the sine (sin) of an angle
/// </summary>
/// <remarks>
///  Returns the Sine (Sin) value of an angle radians value.
///  The value returned will be between -1 and 1.
///  If the angle is zero, the returned value will be zero.
/// </remarks>
/// <param name="Angle">
///   The angle in radians.
/// </param>
function Sin(Angle: Double): Double;

And Delphi IDE will automatically use it for Help Insight, showing you information about the method on-the-fly. For example, if some developer is trying to use the Sin method of your API, information will be conveniently displayed:

xml help insight

The good news is that, with XData, you can use such XML comments in the Swagger document and Swagger-UI that are generated automatically by XData, improving even more your REST API documentation. Since the API endpoints are generated directly from the interfaced and methods, XData knows exactly the meaning of each documentation and can map it accordingly to Swagger.

Enabling generation of XML documentation files

XData needs to read the XML files with the comments to import it into the Swagger document. You need to tell Delphi compiler to generate the XML documentation files.

In your project options (Delphi menu Project | Options, or Shift+Ctrl+F11), go to "Building, Delphi Compiler, Compiling" (for Delphi 10.4.1 Sydney. Previous Delphi version might differ), then enable option "Generate XML documentation". You might also want to explicitly set the directory where the XML files will be generated, in option "XML documentation output directory". It's recommended to use ".\$(Platform)\$(Config)", this way the XML files will be in the same folder as the executable.

xml project options

Importing XML documentation in Swagger

XML documentation usage in Swagger can be enabled with a single line of code:

uses {...}, XData.Aurelius.ModelBuilder;

...

  TXDataModelBuilder.LoadXmlDoc(XDataServer.Model);

Add the line at the beginning of your application, be it in your dpr file, or initialization section of some unit, or in the OnCreate event of your TDataModule that contains your XData/Sparkle components. In the first parameter you must provide the XData model you want to import XML files to. In the example above, XDataServer is a TXDataServer component. If you are using multi-model design, just provide the proper model there.

LoadXmlDoc will try to find the XML files in the same directory as your application is located. If the XML files are in a different folder, you can specify it explicitly using a second parameter:

TXDataModelBuilder.LoadXmlDoc(XDataServer.Model, 'C:\MyXMLFiles');

Once you do that, if you check your Swagger documentation via Swagger-UI, you will see something like this:

xml swagger example

Note how the content of summary tag goes directly at the right of the GET button, as a summary for the endpoint.

The content of remarks tag is the detailed description of the endpoint.

And the content of each param tag explains each respective parameter. Sweet!

Using different documentation for Help Insight and Swagger

Reusing the same XML comments is nice as you don't repeate yourself. Document your code just once, and the same documentation is used for documenting your Delphi interfaces (Delphi developments) and your REST API (API consumer development).

But, if for some reason you want to use different documentation content for Delphi developers and for REST API users, that's also possible. You can use the specific swagger tag to fill specific parts of the documentation. You then use the name attribute to differentiate between swagger tags.

For example, suppose the following documentation:

xml doc source

Note that tags summary (1) and param (2 and 3) are the regular XML documentation tags. They will be used for Help Insight:

xml help insight 2

And swagger tags with no name attribute (A), or name param-A (B), param-B (C) and remarks (D) will be used exclusively for Swagger documentation:

xml swagger example 2

Customizing tags

You can also customize the tags in Swagger. Endpoints are grouped together inside a tag, which can have a name and description.

By default, the name of the tag will be path segment of the interface service. But you can change it using swagger tag with tag-name attribute.

The description of the tag by default is empty, but you can define it using the regular summary tag, or optionally using the swagger tag with tag-description attribute.

Consider the following documentation for both IArithmenticService and ITrigonometryService:

xml tag source

The above tags will generate the following output in Swagger UI:

xml swagger tags

Customizing document header and description

XData also takes the model name, version and description into account to build the final document. You can configure such settings directly by changing some properties of the XData model (remember that XDataServer in this example is a TXDataServer component):

  XDataServer.Model.Title := 'Mathematics API';
  XDataServer.Model.Version := '1.0';
  XDataServer.Model.Description :=
    '### Overview'#13#10 +
    'This is an API for **mathematical** operations. '#13#10 +
    'Feel free to browse and execute several operations like *arithmetic* ' +
    'and *trigonometric* functions'#13#10#13#10 +
    '### More info'#13#10 +
    'Build with [TMS XData](https://www.tmssoftware.com/site/xdata.asp), from ' +
    '[TMS Software](https://www.tmssoftware.com).' +
    'A Delphi framework for building REST servers'#13#10 +
    '[![TMS Software](https://download.tmssoftware.com/business/tms-logo-small.png)]' +
    '(https://www.tmssoftware.com)';

Note that you can use Markdown syntax to format the final text. Here is what it will look like:

swagger doc description