I had a friend tell me today that someone told him...
# general
a
I had a friend tell me today that someone told him NetSuite was going to eventually depreciate SOAP web services. He wanted me to ask here. Did anyone hear of anything like this?
j
They are deprecating SOAP Web Services authentication through user credentials and only supporting TBA.
In fact, I think they put that into practice an update or two ago.
m
If they deprecated ALL of SOAP Web Services the world might collapse lol. I am sure they will deprecate it eventually, but I would be pretty stunned if that is coming in the near term. Maybe in like 5+ years?
n
No longer supported is the right term. If they deprecate it, most of the integrations that are using it will suddenly stop working.
a
Thanks! @Marc Reicher I said the same thing to him about 5+ years. lol
b
their Support for Existing WSDL Versions is actually pretty good, they just started removing older endpoints in 2019.1
m
Yeah they only support 3 years worth of WSDLs I believe
b
with the 4 years after that available but unsupported
m
I am a bit lost on where they are trying to move with the API. Currently, neither SOAP nor REST supports all record types. I know they want to get to a state where REST has all record types, and I imagine at that point they will start conversations about deprecating SOAP. I can't help but wonder if there will be a new API design pattern by then that will trump SOAP and REST lol
s
I would recommend just using restlets - it's usually a whole lot easier to implement and maintain. Depends on your use case, but all too often you end up having to make multiple SOAP/REST api calls to get all of the data you need and it turns into a rats nest very quickly in your integration layer.
r
SOAP logging in netsuite is so much easier to troubleshoot issues that REST imo.
m
@Seth Duda the main reason my team uses SOAP and REST is b/c we manage an integration for hundreds of NetSuite environments. It would be a much bigger nightmare to manage deploying RESTlets (written in SuiteScript) to those environments than it is to just write our our own SOAP/REST code in JavaScript. The big advantage is we can make changes to our integration without having to use something like a managed bundle. We also don't have to hire developers that write SuiteScript. That being said, based on everything I read in this Slack Workspace, RESTlets seem like an overall easier experience, especially if you are just managing one or a handful of NetSuite environments. Curious what your use case is though
s
@Marc Reicher I believe one of the largest integration players with NS (Celigo) relies on restlets to support their standard integrations. Both are definitely valid approaches at all scales. Where companies usually run into trouble is when multiple API calls are required to NS to handle an integration. All too often integration platforms (point and click) are used in the middle where the simple stuff is easy and the hard stuff is annoying difficult or impossible. Restlets provide a clean way to encapsulate complexity outside of your integration layer. If you've build your own integration layer (custom code) outside of a point and click solution, this is less of a concern typically, unless you (a) can't get the functionality you need out of the API, (b) moving logic into NS makes it easier to maintain the integration for the company, or (c) performance is critical and moving logic closer to the data improves performance.
👍 1
Also, for anyone considering using SOAP, make sure you understand what's involved with upgrading SOAP API versions. Sometimes this can be a major hurdle for integration platforms.
Hopefully someone benefits from this thread before it's lost forever to slack message limits. 🙂
m
That all makes sense 👍 Appreciate you sharing your insight!