We are currently developing a frontend-application (js) using the REST API and are facing numerous problems.
First of all, your documentation is awful, lacking and sometimes even wrong, or everything at once. It only contains happy cases, and limited of those also.
Second, none of the API endpoints are consistent with eachother. What is default and behaviour of selectQuery, cannot be used for getRecord, or anywhere else. Some place output codes, some raw values, some formatted values, arrays are splitted by comma, and some by pipe, etc.
Third, even changing output from XML to JSON results in other results. On getRecord, changing from XML to JSON suddenly changes from lookup record names being outputted, to an array of object IDs being outputted. We see that the SOAP API atleast has a "useIds" attribute to control this.
<?xml version="1.0" encoding="UTF-8" ?>
<data id="342171445" objName="complaint4">
<field name="R160819019">FOO123 - Test-artikkel | I DID THIS | OOPS I DID IT AGAIN|BAR 456 - Tort og svie</field>
Fourth, currency outputted via selectQuery and with JSON breaks the JSON output.E.g: select unitprice from complaintpart outputs:
Fifth, many of the APIs follow worst-practice to every aspect.
We are running v4.4.0 on-premise installation. If any of theese is addressed in newer versions, please tell us as we could find no specifics for these major issues. It is very obvious that these areas has not been in focus for development nor testing.
I know this has been a very negatively charged post, but I see no other choice than to address this to you guys so that you can take action and fix it for future users. All this has been a massive time consumer for our project raising the overall time to develop by as much as 60% so far, and we still keep hitting problems.
Do you have any plans to fix your REST API?
I checked the various responses from selectQuery and getRecord with xml and json. Here are the outcomes
Here is some results from trying different datatypes on different endpoints
(separated with \n, changed to line break for readability)
#Thu Nov 26 07:02:04 CST 2015fileSize=243794origFileName=20141130_210026.jpegcontentType=image/jpegfileName=az_4542211430328568468.jpeg
(separated with whitespace, , changed to line break for readability)
#Thu Nov 26 07:02:04 CST 2015 fileSize=243794 origFileName=20141130_210026.jpeg contentType=image/jpeg fileName=az_4542211430328568468.jpeg
<File contentType="image/jpeg" origFileName="20141130_210026.jpeg">
(base-64 encodet data)
Sorry for the delayed response. Thanks for the detailed analysis.
As you pointed out, our APIs currently have following issues
a. Limited Documentation
1. Samples for many scenarios
2. Error handling
3. Input/Output formats for many field types
4. Supported Field Types
1. selectQuery Vs other APIs
2. Date Fields
3. Binary data (File and Image fields)
5. Relationship Fields
6. ID Vs Code Vs Display Name
7. JSON Vs REST
c. Permission Model - API and UI access control differs in some cases
Short Term Plan
We are working on improving documentation and fixing bugs and permission model issues.
So please file any bug you find through Tech Support - we will prioritize them as early as possible.
Long Term Plan
The biggest issue is consistency and we are unable to fix them because most if not all of those changes will break backward compatibility. So we are working a new set of APIs - Rollbase REST 2.0
This would adhere to REST principles, will be standards based and support JSON only as data format.
This would address all your concerns related to documentation, samples, will have a visual REST testing tool built into the product (something like Chrome POSTMAN). All APIs would be consistent including selectQuery which would be built on standard SQL parser.
Hope this helps
This would help for all future uses, and are very welcome! Thank you for your answer :)