REST API and respecting Sugar data business rules

Question

We have used a combination of Studio Required checkboxes, before_save logic hooks and dependency files (Required, SetOptions etc) to enforce some data business rules (including conditional logic) within Sugar instances. 
 I am not a developer, but have a question relating to integration via the Sugar API... 
 If data is presented to the API (for example to write data in), if that data does not meet the business rules around data within the Sugar instance, does the API call reject the data with appropriate error messages that can be interpreted ? 
 If not, does it simply let the data through or would you have to do additional programming around the API to maintain data integrity. 
 Thanks 
 Neil

Neil Conacher · Answer

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

Neil Conacher · Answer

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