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

REST API - field validation, status return & PUT

 Forum

REST API - field validation, status return & PUT

This question is answered

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:

<resp status="ok">
<data id=”314452” objName=”person” />
<Msg>12 fields have been processed</Msg>
</resp>

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".

 

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

  • 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.

All Replies
  • 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

  • Other API types (SOAP and Server-Side) will also considered in this defect.
  • createRecord only returns the id and objName of the newly created record. No message nor status.

  • 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.

  • 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.

  • My apologies for the confusion. I have updated my previous post. :-)
  • 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.

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

  • You're welcome!


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

  • 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'.

  • Valid point, I'll fix this as well.

  • 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().

  • 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.

  • 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.