When Steve‘s employer went hunting for a new customer relationship management system (CRM), they had some requirements. A lot of them were around the kind of vendor support they’d get. Their sales team weren’t the most technical people, and the company wanted to push as much routine support off to the vendor as possible.
But they also needed a system that was extensible. Steve’s company had many custom workflows they wanted to be able to execute, and automated marketing messages they wanted to construct, and so wanted a CRM that had an easy to use API.
“No worries,” the vendor sales rep said, “we’ve had a RESTful API in our system for years. It’s well tested and reliable. It’s JSON based.”
The purchasing department ground their way through the purchase order and eventually they started migrating to the new CRM system. And it fell to Steve to start learning the JSON-based, RESTful API.
“JSON”-based was a more accurate description.
For example, an API endpoint might have a schema like:
DeliveryId: int // the ID of the created delivery
Errors: xml // Collection of errors encountered
This example schema is representative. Many “JSON” documents contained strings of XML inside of them.
Often, this is done when an existing XML-based API is “modernized”, but in this case, the root cause is a little dumber than that. The system uses SQL Server as its back end, and XML is one of the native types. They just have a stored procedure build an XML object and then return it as an output parameter.
You’ll be surprised to learn that the vendor’s support team had a similar level of care: they officially did what you asked, but sometimes it felt like malicious compliance.
[Advertisement]Utilize BuildMaster to release your software with confidence, at the pace your business demands. Download today!
Source: Read MoreÂ
