In layman terms, an API, or Application Programming Interface, is an approach to software architecture that permits exposing a system’s capabilities and/or data, to other, external systems. ElectionsOnline is the only election service provider to offer an API and has been doing so for years, allowing clients to consume the ballot created at ElectionsOnline into their own website. However, that API followed the SOAP architecture. Today, I’m happy to announce the SOAP API is being superseded with a new REST-based API.
Why is this a big deal?
There are enough resources on the web already that delve into the pros and cons of SOAP (Simple Object Access Protocol) versus REST (Representational State Transfer) web service APIs. I have nothing to add to that, but suffice it to say the simplicity of REST lowers the barrier to entry. Organizations that have been intrigued by the prospect of integrating the ballot into their own website, but simply didn’t have the resources to handle a SOAP integration, may now wish to reconsider.
Are the SOAP web services going away?
If you’ve already integrated using the SOAP API, don’t worry, it isn’t going anywhere. The new RESTful API is being offered in addition to, not in place of, the SOAP API. In fact, the code that drives this new REST API will still have an associated WSDL file and can be consumed using SOAP, or one could even step completely outside a SOAP or REST model, and simply post form variables to the web service files directly. There is no advantage to doing that and since the REST architecture is the only approach that will be supported with documentation, it’s obviously where the future is headed.
New functionality added to API
There’s more than just the adoption of REST that has been added to these web services. Until now, the only capability exposed through the API was the ability to consume a ballot into a client’s own website. That capability is preserved, but has been simplified not only by the adoption of REST, but also by virtue of the service not requiring as many parameters to be passed into it.
While the ability to consume the ballot is the most fundamental thing a client will want to do via an API, the ability to perform CRUD (Create, Read, Update, Delete) operations on the following resources has been added:
- Voters
- Positions
- Candidates
Use case for the new resources
By exposing these three new resources through the API, an external system, let’s say an AMS (Association Management System) for example, could support the ability to add candidates to their election setup directly from within their AMS. Why take that approach? Wouldn’t it be just as easy to add candidates to a ballot inside the ElectionsOnline system? Well yes, it would be just as easy. But consider this, when an association member votes, that activity can be factored into that member’s engagement score. It stands to reason then, that running for office should also factor into a member engagement score. By adding candidates to a ballot directly within an AMS, the act of running for an elected leadership position could be captured in that member’s activity history and included in their engagement score without a two-step process of them being manually typed into the ElectionsOnline system, then also flagged in an AMS as having ran for office.
Conclusion
This is an exciting development that further solidifies ElectionsOnline’s reputation for being the industry’s leading innovator and also the leading integrated election solution. For more about why integration is a good thing, see 4 Advantages to Integrating Evote Into Your Own Site and visit the Integrations page for more examples of how ElectionsOnline’s Evote can play nicely with your organization’s technology ecosystem.
