| > And how is it that a "good API" requires client modules for all these different languages? Do people not know how to make HTTP requests anymore or something? That is a complex question. For example, our company's ERP is a niche product specific to the printing industry. It has a SOAP API, and a WSDL so large that it will crush any SOAP library that is not doing code generation. We are one of only a handful of their customers who are NOT using their pre-generated SDKs because we do everything in Python and Elixir, and they only provide SDKs for Java, PHP, and .NET. They rely upon the SDKs to provide API documentation, rather than the WSDL. The CRUD endpoints are consistent and work well - until they don't, and then you have to guess why a call failed due to some undocumented business rule. The process endpoints are a nightmare. Every call is documented as follows: Name, number of parameters. That's it. Parameters are all called IN0 through IN9. There is no documentation specify what the parameters are, which ones are required, what the data types are, or acceptable values/ranges. We have to dig through the SDK code (usually PHP) and make guesses. To make matters worse, the state-side developers didn't write and don't maintain the API. It's offshored, and any question takes a couple weeks to get answered. I realize that none of this is SOAP/WSDL's fault. But the fact that the vendor can get away with this shows how many shops really truly can't handle simple HTTP requests, and are hamstrung unless the vendor supplies an SDK. Otherwise the vendor could never get away with this. As an aside: We ended up writing a REST microservice to translate JSON calls to SOAP for CRUD. (This was also necessary because we discovered that if we did not rate-limit the SOAP calls, the ERP choked). This dramatically simplified our integration code. But to this day, through we have repeatedly requested it, we cannot get full documentation on the process calls. |