REST API and respecting Sugar data business rules

Hello Neil,

nice to see you in the Club!

I'm not a developer too, so let me answer with video - editing the record with required field via interface vs creating new record via API with Postman (double-click for the full screen when viewing)

As we may conclude from this simple example, the answer is No - in general, with no additional efforts, we can't be sure that all the business logic implemented is respected when using API

To the best of my knowledge the short answer is it depends.

And yes, it gets complicated and whoever uses APIs to enter data needs to know your particular implementation intimately. 

Developers can add logic and controls in Sugar, as you stated, in several ways.

Many of those controls were developed to prevent the end user of the Sugar interface from doing certain things, like entering anything random in a dropdown field. At the database level a dropdown field is just a varchar, so you can put anything you want in there as long as you respect the field type and length. The interface is the one that prevents you from doing so.

So those types of controls, like, for example: Studio Required checkboxes, Dependencies, and any View controller  (like code in your module's create.js or record.js)  do NOT apply to APIs, those are tied to the Sugar Interface. They are "tricks" of the Sugar interface.

Even things like Dropdown Values will NOT be checked against your lists or enforced unless your API explicitly does so, and most do not.
So you need to make sure that the application that uses the REST API for data entry knows about those, and that the developer of that application uses the appropriate Metadata APIs to retrieve the pertinent information and use it appropriately.
Out of the box, there is nothing stopping you from passing invalid options to dropdown fields via API.
What is worse is, you will never know that data is in there unless you look at the table data with a direct select statement, the interface will not show any values, so bad values look the same as no values (some developers have commented in the club through the years about that and how removing values from the dropdown list no longer shows those values, so there is no easy way to make a value "obsolete" but retain it for older records).

Dirty data is your worst enemy and a careless use of APIs can easily put some in.

Out of the box APIs, or at least all the ones I've looked at, use BeanFactory to create, retrieve, and manipulate records. This means that they create/update Sugar module beans which are then saved. Because of that, most Out of the Box APIs will trigger your before/after save logic hooks. However, if you have developed your own APIs, there is no saying what the developer did to implement them. They could be using direct database SQL Inserts, in theory, and those would not trigger any logic hooks.

Even if using a properly developed API which follows Best Practices is developed, as those out of the box are, you still need to make sure that errors are handled correctly by both the API and the application that calls the API. Someone has to know that something went wrong...

So as you see the answer is not a simple yes or no. It is complicated, it requires careful and detailed knowledge of your particular system, your customizations, and the application that you are using to call the APIs in the first place.

I hope this gives you a bit more of a picture of what you can expect.

I'll be glad to try to answer any specific questions you might have.

FrancescaS

Francesca Shiekh - thanks for your comprehensive response and that makes sense to me. As you describe, ensuring clean data is an ongoing challenge, particularly in today's world of integration. As you touch on, there are areas where Sugar could be more rigorous in highlighting data which has been orphaned from a DD list.

Dmytro Chupylka - thanks for that - good visual confirmation and helps my understanding

To Francesca's point, it is best to assume that the business rules will not be validated, but there are some checks that do take place. For example, date fields must contain values that are formatted as yyyy-mm-dd or the record (creation or update) will be rejected. 

It is assumed that the developer will build in the necessary logic that validates the data before it is submitted to the Sugar API. If you wish to build in custom validations, it is also possible to do that, through the validation constraints framework.