REST API - field validation, status return & PUT - Rollbase - Forum

Posted by matman on 21-Oct-2014 10:07

Field validation
I was testing some things in the REST API and noticed some things. updateRecord completely ignores the field validation on one of my fields. It should return: [ return "Nope!"; ]. Instead it just changes the value to the value set in the URL parameter.

Status return
According to the REST API documentation, createRecord should return a status field. This was told in the output example on page 726:

&lt;resp status="ok"&gt;
&lt;data id=”314452” objName=”person” /&gt;
&lt;Msg&gt;12 fields have been processed&lt;/Msg&gt;
&lt;/resp&gt;

However, It doesn't seem to return any status field for me on succes.

PUT request
The REST API tells me that the HTTP method for updateRecord is either PUT or POST. When I call updateRecord using a PUT method, the REST API returns an error message saying: "Unknown API for PUT request updateRecord".

Rollbase - Forum

All Replies

Posted by pvorobie on 21-Oct-2014 11:20

1. Field-level validation rules are ignored in updateRecord and other REST APIs: this is a bug PSC00317166, will be fixed

2. Your status message is "12 fields have been processed"

3. PUT does not accept updateRecord API, this is a bug, will be fixed along with PSC00317166

Posted by Godfrey Sorita on 21-Oct-2014 12:53

Other API types (SOAP and Server-Side) will also considered in this defect.

Posted by matman on 22-Oct-2014 03:31

[mention:05b5f00eae4a468d844fa8bedcafd110:e9ed411860ed4f2ba0265705b8793d05] createRecord only returns the id and objName of the newly created record. No message nor status.

Posted by Godfrey Sorita on 22-Oct-2014 09:37

The response seems to vary depending on the value of the 'output' parameter.

When JSON output is used, it may return 2 different set of nodes:
1. Success -> Data (ID and objectName)
2. Failed -> Status & message

All the nodes are complete when XML output is used.

I will include this in defect PSC00317166. You can use 'id' to determine the status for the meantime.

Posted by matman on 22-Oct-2014 09:58

Hey Godfrey, thanks for the information, it helps me decide whether everything went OK or not :) However, createRecord returns node 2 (Failed) on success. I can also see that the record was added to my application object.

Posted by Godfrey Sorita on 22-Oct-2014 10:05

My apologies for the confusion. I have updated my previous post. :-)

Posted by matman on 22-Oct-2014 10:12

Not a problem! Perhaps it would be nice to add a consistent way of giving feedback? deleteRecord always returns "status" that equals either "ok" or "failed", but createRecord only returns "status" on failure.

EDIT: Nevermind, I currently think this would bring more complications than solutions. Adding a "status" field to getRecord could override a field named "status" and vice versa.

Posted by pvorobie on 22-Oct-2014 12:19

I will add "status": "ok" to response from createRecord API for consistence. Thanks for noticing.

Posted by matman on 23-Oct-2014 08:36

[mention:05b5f00eae4a468d844fa8bedcafd110:e9ed411860ed4f2ba0265705b8793d05] You're welcome!

I noticed deleteRecord ignores object condition formulas for deletion. (Perhaps updateRecord ignores the condition formula for edit too?)

Posted by matman on 23-Oct-2014 10:30

createRecord ignores required relationship fields, but doesn't ignore required non-relationship fields. (The same may count for updateRecord?) This causes orphan records, which means a record deleting trigger may need to be added which triggers on 'After update' and 'After create'.

Posted by pvorobie on 23-Oct-2014 10:39

Valid point, I'll fix this as well.

Posted by matman on 24-Oct-2014 05:17

Thanks! By the way, I hope I'm not bothering you guys with all the stuff I dump here...

I would like to suggest something for deleteRecord. deleteRecord currently only required "id" to delete something. Because "objName" could be left out, pretty much anything that you're allowed to delete with an id could be deleted. I think it would be better to make objName required, as this also matches rbf_deleteRecord() and rbv_api.deleteRecord().

Posted by pvorobie on 24-Oct-2014 12:15

This is for backward compatibility. All "native" Rollbase records have globally unique ID. So, unless you're working with External objects, it is OK to skip objName.

Posted by Manooj Murali on 25-Nov-2014 05:01

With custom field validation enabled, we see backward compatibility issues for existing customers. So, we are going to provide this as a configurable feature in Private cloud in 3.1. We have a new shared property CustomValidationViaAPI which is defaulted to true in private cloud distributions and false in public cloud.

True -> Custom Field Validations will run.

False -> Custom Field Valdiations will not run.

Customers who face issues with regards to custom field validation after 3.1 upgrade (private cloud) can set the shared property to false.

Please note that this configurable switch is only for backward compatibility reasons and will be removed in future releases.

In future, custom field validation will be enabled by default even on public cloud.

This thread is closed