REST API (Page 2 of 4)

Create a Sales Invoice and use the Slim API to GET that invoice - you will get the json value. Form your new Invoice in json accordingly and use the PUT endpoint to inject your invoice. Putting in such an invoice will not have the Sales Order, Sales Delivery and Customer Payment that would need to have their own PUT requests in place (or does it?).

I'm sure you can now parse the code and determine what you need. The community has put in sufficient effort in double quick time to assist you among others. Hopefully you too will contribute tested code to it once you get familiar.

This is what makes Open Source tick.

@s4m3shms I have started some documentation here but it is a long way from complete.  It is auto generated from comments in the code and I haven't the time to do that all in one go.  But its a start.

In the mean time you can learn how to use the SimpleAPI from the tests that are in the source (but excluded from the package).

https://github.com/cambell-prince/Front … r-cp/tests

As an example, the sales test shows how to list, create, update, and delete a sale.

If anyone wants to see the source annotations for the documentation you can have a look at the feature/docs branch in GitHub.

Hello Cambell

This is extremely useful. I am going through all of them.

Regards
Sume MS

@s4m3shms I've just got the api working accepting JSON input with a Content-Type: application/json, its only working on my machine right now.  I'll code a unit test and hope to ship a release tomorrow.

Hi Cambell

It worked with Content-Type: application/json!

There is a mismatch in the parameters with GET and POST. I had to go through the source to get the correct parameter.
Or can I get the correct parameter type somewhere?

For example when using GET api/category we get:

{"category_id":"1","description":"Components","dflt_tax_type":"1","dflt_units":"each","dflt_mb_flag":"B","dflt_sales_act":"4010","dflt_cogs_act":"5010","dflt_inventory_act":"1510","dflt_adjustment_act":"5040","dflt_wip_act":"1530","dflt_no_sale":"0"}

but I had to POST with this

{"tax_type_id":"1","units":"each","description":"Test9","mb_flag":"B","sales_account":"4010","cogs_account":"5010","inventory_account":"1510","adjustment_account":"5040","wip_account":"1530","dflt_no_sale":"0"}

where dflt_units is replaced with units
dflt_mb_flag is replaced with mb_flag
dflt_sales_act is replaced with sales_account .. and so on

Thanks anyway , keep going..

@s4m3shms I'm working on refactoring the tests and ensuring consistency in GET, POST and PUT for all endpoints based on your feeback (with tests).

@apmuthu.  Thanks! Fixed in https://github.com/cambell-prince/FrontAccountingSimpleAPI/commit/d3d183aa733d562e2de8536bd8f7ce3a672ae781

I've released version v2.4-1.4 of the Simple API for Front Accounting.  You can download it here:

https://github.com/cambell-prince/FrontAccountingSimpleAPI/releases/tag/v2.4-1.4

This release ensures consistency in the api parameters between POST (Create) and PUT (Update). Also ensures parameters are named consistently with their use in Front Accounting 2.4.

- Refactor tests to ensure consistency in POST and PUT api.
- Added tests/Crud_Base.php
- Add api_ensureAssociateArray to remove the numeric index elements that come from the Front Accounting functions.
- The category end point now follows the database schema more closely for property names.
- The customers end point now follows the database schema more closely for property names.

Thanks @apmuthu and @s4m3shms for testing and providing feedback.

@s4m3shms Hopefully you will now find the GET, POST and PUT behavior more consistent.

My releases work without composer also.  composer is a developer tool, not an end user tool.

Thanks guys for the excellent works!

I have tested @cambell's version , as you said GET, POST and PUT behaviors are more consistant.

Both @apmuthu and @cambell versions work without any hastle without any dependancy configuration.

I will continue my testing and post the updates.

Regards
Sume MS

By end user I mean those who install, maintain and use FrontAccounting by themselves with the Slim API, not the FA application operatives using what someone else installs and maintains.

What is wrong with line 6 of index,php? Just a plain include of all php files in the src folder so that any function in any endpoint can use it. I am planning on working on it to make sure that native FA functions are used for the most part. It works for me.

If there is anyone for whom the code does not work, please let me know - I'd like to know why and will do what needs to be done. I am keeping it as backward compatible as is possible so that those on older PHP versions too can still keep their installs whilst leveraging the REST API.

If you put in some test access values in util.php, you can easily browse to say: http://localhost/fa24/modules/api24/category/1

I've been packaging the original submission from Andres Amaya Diaz for FA 2.3 and worked on it while it was being hammered out. You check the wiki history and the original threads too.

Hi, I'm not sure about paths,

I'm getting:-

Use of undefined constant VARLOG_PATH - assumed 'VARLOG_PATH' in file: /home/path/path/path/config.default.php at line 32

Use of undefined constant VARLOG_PATH - assumed 'VARLOG_PATH' in file: /home/path/path/path/config.php at line 32

include_once(./vendor/autoload.php): failed to open stream: No such file or directory in file: /home/path/path/path/modules/api/index.php at line 41

include_once(): Failed opening './vendor/autoload.php' for inclusion (include_path='.:/opt/alt/php56/usr/share/pear:/opt/alt/php56/usr/share/php') in file: /home/path/path/path/modules/api/index.php at line 41

Class 'Slim\Slim' not found in /home/path/path/path/modules/api/index.php on line 54

Is this defined in File: /home/path/path/path/config_api.php

01: <?php
02: 
03: if (file_exists(__DIR__ . '/_frontaccounting')) {
04:     $rootPath = realpath(__DIR__ . '/_frontaccounting');
05: } else {
06:     $rootPath = realpath(__DIR__ . '/../..');
07: }
08: //Tried this results as above
09: // define('API_ROOT', $rootPath . '/modules/api');
10: // define('FA_ROOT', $rootPath);
11: //tried this same results
12: define('API_ROOT', '.');
13: define('FA_ROOT', './../..');
14: 

Or somewhere else?

What should the path be?

Hello Cambell

I was testing the sales APIs from your latest repository, none of the methods worked for me.

For example:

http://url/modules/api/sales/
or
http://url/modules/api/sales/5

returns nothing.

Whilst other api method are working fine.

Is there any updates?

Regards