API Specifications FinSpec
Almost month has passed since we open-sourced FinSpec Schema 0.1, our vision of what we believe multi-protocol, electronic specifications for financial services should look like. If you still haven't checked it out, head over to https://github.com/finspec/finspec-spec.
Thanks for the overwhelming reception, all the encouragement, suggestions, and most importantly contributions. Suggestions based on real-world examples of specs in a variety of protocols have been most valuable as we enrich and mature the schema, so please keep them coming.
We've been busy working on version 0.2 of the schema, which is now live. Here's a summary:
General Added ability to specify charset, whether API is binary or text, and default endianness of a spec.
Data types Instead of having predefined and growing list of field datatypes, and forcing API consumers to deal with datatypes that may not be useful for their API, we've added the ability to define the custom datatypes. In addition to basic type, you have more control to define length, precision, sign, regular expression pattern, padding and much more for the datatype.
Common blocks Added commonBlocks section to define blocks that are common across all messages, such as header and footer blocks.
Fields We've added more controls to define a range (minValue - maxValue) for numeric fields, specify required regex patterns, as well as the ability to capture conditions specific to given field (see below).
Field conditions We hope to finally free API authors from simplistic “is it required? (Yes or No)” columns, to a world where fields can be conditionally required (or absent) when other conditions are true about the message. It's now simple and easy to explain that Price is a mandatory field for Limit orders, but shouldn't appear for Market orders. Check out the documentation for more.
So please check out the version 0.2 schema, documentation, and examples on github and see how you can use it. Remember that the license allows you to freely use this schema for internal purposes, or to publish to clients.
Create github issues or drop us a line at email@example.com, if you need help or have any feedback or suggestion. Let's all discuss, contribute, and promote to take the schema to next level!