Every COFIQ account gets a free example model to demonstrate the power of COFIQ and play with.
A few examples of its (automatically generated) output:
  1. Banking Vocabulary - PDF report
  2. CashManagementServiceV1 - PDF
  3. CashManagementServiceV1 - WSDL
  4. CashManagementServiceV1 - JSON HYPER SCHEMA
Another example to show that COFIQ can handle technical API's as well as API's for administrative applications. It is very loosely based on Philips Hue API, which was crowned as the best 'Internet of Things' API. With COFIQ you can define a winning API for your own 'things'. This example shows the power of using REST messages combining URI and Body message parts to achieve optimum easy of use for your app developers. To be absolutely clear this is not meant to interact with Philips Hue, it is meant to develop your own API for your 'Internet of Things' devices. These examples demonstrate the value of COFIQ, just imagine what it would mean to manually maintain this in a guaranteed consistent way. COFIQ does this for you!
  1. Domotica Lighting API V1 - JSON HYPER SCHEMA
Here's the vocabulary, PDF service report and a more traditional SOAP .wsdl file. All from a single service definition as entered in the COFIQ repository.
  1. Domotica Lighting API Vocabulary - PDF report
  2. Domotica Lighting API V1 - PDF
  3. Domotica Lighting API V1 - WSDL
And...some articles you may find inspiring in pursuing the benefits of service orientation:
  1. Your SOA Needs a Business Case
  2. API Design Matters, Michi Henning
    Uses the .NET Socket API as an example, but is also applicable to business level SOA and Public Website API's. It is especially clear on the importance of:
    Stability of your API: The subtitle of the article says "Why changing APIs might become a criminal offence".
    Contract-first: "...APIs should be documented before they are implemented. A big problem with API documentation is that it is usually written after the API is implemented, and often written by the implementer. The implementer, however, is mentally contaminated by the implementation and will have a tendency simply to write down what he or she has done. This often leads to incomplete documentation because the implementer is too familiar with the API and assumes that some things are obvious when they are not. Worse, it often leads to APIs that miss important use cases entirely. On the other hand, if the caller (not the implementer) writes the documentation, the caller can approach the problem from a “this is what I need” perspective, unburdened by implementation concerns. This makes it more likely that the API addresses the needs of the caller and prevents many design flaws from arising in the first place. ...".
    Vocabulary: "...Conversely, the designer of an API cannot help but dictate to the caller a particular set of semantics and a particular style of programming. ...".
    RIGHT!
  3. The Business Does Not Exist
  4. Smart SOA and the DEMO methodology for modeling enterprises
  5. Recession Proof SOA
  6. The Amiable API
  7. Great site with more articles, video's and book references on API design.
  8. Three Myths about Canonical Data Models
  9. Brilliant article by Maarten Bernards on the best practice of using canonical data models. Translated from Dutch especially for COFIQ. Thanks Maarten!
    Forms an excellent basis for effective use of the COFIQ system.