I am not sure how i'd feel w/ netsuite owning a rest service I depend on daily. If it were me, I'd rather have full control over the RESTlets so i can do what I need to when I need to do it vs. having to talk to NetSuite for any issues/updates required. Yeah you get some native functionality to do rest calls, but at what cost ultimately?

+1 ... and a RESTlet won't change without you actually changing it! (can you tell I don't trust NetSuite :)) Also +1 for battk's comment, I've been in development and IT for over 25 years and will always wait to either sp1 or a good 12 months after release before even thinking about production code.

Agreed. The integrations that I work on are too important to be anything but rock solid - and at the moment, SuiteTalk REST is far from that. To some extent, RESTlets take more work to get in place. But the control and stability that they offer are worth the effort.

I've spoken to @tdietrich about this, but I can give you my company's use case for strongly preferring a REST API, even if it breaks periodically. We have a standalone app (outside of NetSuite) that serves hundreds of NetSuite clients. It's much easier if we can hit a REST API without having to deploy RESTlets to hundreds of different NetSuite environments. If the REST API introduces a breaking change, we can update and redeploy our code in a day without having to worry about pushing that code to different NetSuite environments, dealing with Managed Bundles, etc. I would agree if you are managing one NetSuite environment, the REST API is probably pretty pointless

With bundles/suiteapps (bundles are being sunset), you can instantly deploy a restlet change too so I'm not sure how it helps you out. Are you saying you just want to avoid having to create/maintain RESTlets at all?

Right it's doable, but it introduces an entirely new code deployment pipeline that we have to manage

gotcha I assumed thats what you were doing was a managed bundle. That makes total sense now.