We are about to start GPS tracking development using C# and web services to communicate with a third party java’ish receptor on the hardware units.
We have a contract for the handling of the vehicle GPS unit to cloud exchange. We need to integrate the cloud to consumer integration for our current real time tracking view portion of our software.
I’ve been given the task to create a method of using web services to relay the data in to our application. The data will consist, initially, of few and basic elements; lat, long, vehicleid, etc. Given the nature of GPS ‘real-time’ viewing this needs to be as fast as possible with small bandwidth consumption.
It has been suggested to me to use a web service that simply passes comma delimited data. I’ve been unable to find anything along these lines.
I’m open to any suggestions as I’m new to C# since our application is in VB currently. These are the requirements given to me so far:
- Fast!
- Low bandwidth consumption
- Consumable by the following technologies; ASP.NET, IOS, VB, and VB.NET
JSON would be a good choice. It’s relatively efficient and it’s easy to implement using WCF REST or MVC Web API. Many people aren’t old enough to remember the bad old days of comma delimited files, but I would caution you not to use the format, mainly because it is neither standardized nor supported by mainstream components.
CSV seems like a simple format at first glance because it has a very simple specification: just separate everything by commas. But the devil is in the details, for example quoted strings and escapes for commas and quotes. Perhaps the main problem with CSV is a human factors issue: many developers think they already understand the format, so they tend to make decision about escaping and quotes differently. Although there is a standard, it is generally not followed. There is an interesting discussion of lack of standardization problem as well as some other specific issues on Wikipedia.
JSON is a standardized format with very little room for interpretation (there is some wiggle room on date representations). If you keep your JSON property names short, you can achieve an over the wire efficiency that is close to what you would see in a CSV file (if you’re presenting to management, it might be a good idea to mock up a JSON vs. CSV payload with actual overhead figures). And you can be reasonably sure that when clients communicate with your service, they will be using well known and well tested JSON parsers. Finally, if IOS is present in your client platform requirements, it’s not unreasonable to expect that HTML5 will be added at some point, and JSON is naturally a good choice for HTML5.