Archived older documentation - Burti Rest API

What is REST API?

A RESTful API is an application program interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data.

A RESTful API - also referred to as RESTful web service - is based on representational state transfer (REST) technology, an architectural style and approach to communications often used in web services development.

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. An API for a website is code that allows two software programs to communicate with each another. The API spells out the proper way for a developer to write a program requesting services from an operating or other application.

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. 

How to set up Burti REST API?

Initial setup is rather complicated, so we do it for the costumer. However, there are some prerequisites that needs to be done, in order to set it up:

1. HAL License - this is a customisation to your standard system so you need HAL licence in order for it to work
2. HAL files for Burti REST API - we will install compiled version of HAL files that allow to generate the REST API interfaces based on your systems database configuration
3. Separate setup for each register customer wants to use - we run maintenances for each register you need to use with REST API, but can train you to do that yourself
   
   

How to use Burti REST API?

It is necessary to create script in server folder run-burti-web-api-requests.sh that will contain requests to the server, using the curl command-line tool:

curl "http://localhost:1402/Web_JSON_Composer.hal" -d @sample.get.data.txt > response.get1.json
curl "http://localhost:1402/Web_JSON_Composer.hal" -d @sample.get.data2.txt > response.get2.json
curl "http://localhost:1402/Web_JSON_UpdatingComposer.hal" -d @sample.post.data.txt > response.post.json

The requests are as follows:

Request full details for a specific Item

sample.get.data.txt - made to the READ interface Web_JSON_Composer.hal:

0_query=Web_JSON_INVc_List.hal&0_full=true&0_index=Code&0_Code=10101&0_company=1&0_fieldcnt=1&0_fieldlist=Code

Parameters explained

As you can see, all the parameters are prefixed with a "0_" - this is a number for the request, and is used to make multiple data requests within a single API call. In this example, there is only one data request.

1. query - the specific data interface (will be a separate interface for each register). In this case it's "Web_JSON_INVc_List.hal" for Items (register code INVc) - the naming of this interface will be the same accross all registers.
2. full - whether to request the full data or a shorter list of fields - these fields are configured separately
3. index - the index in Hansaworld's datadef, by which to lookup the data, advanced topic, simply use "Code" (might be something other for other registers)
4. Code - the field name within the index, simply use "Code" (might be something other for other registers)
5. fieldcnt - number of fields within the index, use 1 (might be something other for other registers)
6. company - the company number from which we are requesting the data
7. fieldlist - list of the fields within the index, comma separated, use "Code" (might be something other for other registers)

Response file response.get1.json

Request full list of items

sample.get.data2.txt - made to the READ interface Web_JSON_Composer.hal:

0_query=Web_JSON_INVc_List.hal&0_count=500&0_full=false&0_sort_only=true&0_index=Code&0_company=1&1_query=Web_JSON_INVc_List.hal&1_count=500&1_full=false&1_sort_only=true&1_index=Code&1_company=2

Parameters explained

In this example you can see that there are two groups of parameters - prefixed with "0_" and "1_". This illustrates two separate data requests within a single call. The response data will be similarly grouped.

Only describing new options that are not described above:
# sort_only - this will use the provided index name as a sort order only, and will not try to look up specific data (used when listing all records within a register)

Response file response.get2.json

Insert a new item

 sample.post.data.txt - made to the WRITE interface Web_JSON_UpdatingComposer.hal:

{
	"0": {
		"name": "WEB_JSON_INVc_Save.hal",
		"company": 2,
		"data": {
			"action": "insert",
			"matrix": [],
			"Code": "10101",
			"Name": "Media keyboard"
		}
	},
	"2": {
		"name": "WEB_JSON_INVc_Save.hal",
		"company": 2,
		"data": {
			"action": "insert",
			"matrix": [],
			"Code": "10102",
			"Name": "Media keyboard 2"
		}
	}	
}

Parameters explained

As you can see, the request is now in JSON format. It is once again numbered and can contain multiple requests within the single call. These would be expected to be numbered 0, 1, 2 and so on.

1. name - the name of the update interface. The principle is similar to the read interfaces.
2. company - the company number to use for inserting data
3. data - the data block
4. action - insert/update/delete
5. matrix - to be used with matrix rows - array of rows in the same format as the following
6. Code, Name - database fields to update with values

Response file response.post.json It contains no warnings or errors, but the format in which such errors would be received, can be seen in the file.