Table API or Web service import set/Scripted Rest API? Whats recommended?

[Suggy]

We have a requirement to allow external tool to create/udpate Incidents in our instance. No custom fields, no validations required. Its straight forward create/update.

Person 1 argues that he wants to use Table API, as its simple, straight forward and that is why ServiceNow has exposed APIs for ALL tables.

Person 2 says Table API should NEVER be used, its not a best practice, Irrespective of whether you need validation etc or not, you should instead use Web service import set/Scripted Rest API should be used. 

Person 1 again says then why ServiceNow exposes table API for all tables etc 

So I am actually looking for if there any Authoritive Source of REST API Best Practice out there that explains various scenarios and how to reach the best solution using the various techniques available in ServiceNow.... should Table API never be used or can be used? Rationale behind that etc.

Thanks in advance!

[Elijah Aromola]

Yes it is fine to use the table API.

[Aman Kumar S]

Hi @Suggy ,

It comes down to what are you trying to do exactly. If it is straightforward Create, update, Retrieve or Delete operation of a record, Table API is way to go.

But if you want to do carry some manipulation of data and have some sort of internal logic processing before you put across the data Scripted REST API is the way to go.

[jaheerhattiwale]

@Suggy 

Actually ServiceNow certification team don't allow directly writing to target table (basically OOTB tables), they want us to create a staging table (import set table) and then using transform map to move data to target table. They tell using table api insert data in staging table and then from there use transform map.

Its only to make sure we don't make more api calls to target table.

If we make the api calls in controlled way then we can use table APIs.