Table of Contents

About Burti REST API

What is a REST API?

Simply put, an API  is set of rules developed to expose data and functionality across the internet in a consistent format. Representation State Transfer (REST) is a term used to refer to API generally being accessed via HTTP protocol.

Resources often have one or more methods that can be performed on them over HTTP, most popular of them being, GET, POST, PUT and DELETE.

Burti REST API resources provides information or content, which can be accessed at a predefined set of URL and returns JSON-encoded responses, and uses standard HTTP response codes, authentication, and verbs.

Burti, for example provides REST APIs for {this solution, this and this … ????}

Advantages of using a REST API?

Flexibility

A RESTful API breaks down a transaction to create a series of small modules. Each module addresses a particular underlying part of the transaction. This modularity provides developers with a lot of flexibility.

Suited for WEB

REST technology is generally preferred to the more robust Simple Object Access Protocol (SOAP) technology because REST leverages less bandwidth, making it more suitable for internet usage. 

Prerequisites to using Burti API

Hansa Application Language license

To make use of the Burti REST API a HAL license is required. The license might come included in your product's base package, depending on your country and the product you are using, but typically this will not be the case (e.g. with Standard ERP).

Hansa Application Language knowledge optional

To take advantage of the more advanced aspects of the API, you will benefit greatly from having some HAL programming knowledge or a HAL programmer's assistance. For simpler use cases this might not be necessary.

Burti API license

Burti API is not included in Standard ERP base package. You will need to acquire a license from us and as soon as the formalities are settled, you will be provided with the API module package and an enabler key file. These are files that you will need to place on your server. 

Contents of the package:

Exec_file("halcust/datadefEN.hal");

Setting up

Burti API package and product enabler key

When 

Security

There are several layers of security that can and should be implemented to protect your data and your API transactions from snooping from unwanted parties. As a minimum we recommend configuring and using HTTPS in tandem with an authorisation token. This will ensure that the data you send and receive over the API is virtually impossible to access by unauthorised third parties.

HTTPS (HTTP over SSL or HTTP Secure)

Burti API can be accessed both via HTTP and HTTPS, but it is strongly encouraged to serve your data over HTTPS only (this means disabling HTTP altogether). This will ensure that your traffic is encrypted and safe from third party snooping.

Firewall white-listing

Normally the parties accessing API's reside at fixed network addresses. This is not always the case, but does apply for scenarios like web stores, connections with logistics companies, reporting tools and many others. If you are providing access to software or tools that does reside at a fixed IP address or addresses, consider only allowing access to your server from these addresses in your firewall if you have one in place, or setting one up if you do not already. This way other parties will not be able to connect to the API at all, unless you explicitly allow them by whitelisting in your firewall software or hardware.

Authorisation token

Burti API can and should be configured to require a secret token for all transactions. Consider this a password. Usage of the API without a token should be limited to testing environments only.

Custom security via HAL

Burti API allows you to implement additional layers and logic to control who and how can access the API as a whole or separately for its' endpoints. As us for more details on how to do it, as this is an advanced topic and will require HAL programming.

Interface generation

Read API

Write API