anchor.diff:  * rückwärtrskompatibel
   ** Wenn Änderungen immer rückwärtskompatibel durchgeführt werden können, dann ist es nicht nötig mehrere Versionen zu haben
   ** Beispiel ein sehr einfacher Service
  +--
   
  +=== Welche Änderungen können nicht rückwärtskompatibl sein (SOAP)?
  +
  +[%step]
  +* entfernen und umbennen von Operationen
  +* verändern (Reihenfolge oder Typen) der Parameter in Operationen
  +
  +[NOTE.speaker]
  +--
  +* KÖNNEN, weil ich im Moment der Anpassung nicht weiss, ob der Teil den ich ändere tatsächlich von einem Konsumenten genutzt wird
  +* wir haben eine SOAP und REST Welt
  +--
  +
  +=== Was sind nicht rückwärtskompatible Änderungen bei SOAP & REST ?
  +
  +[%step]
  +* löschen von Attributen in Datenstrukturen
  +* umbennen von Attributen in Datenstrukturen
  +* bei Requests Attribute von optional auf mandatory setzen
  +* bei Antworten Attribute von mandatory auf optional setzen
  +* bei enums hinzufügen/löschen von Werten
  +* bei Strings, andere Werte zurückschicken, z.B. "1. Klasse" statt "1. KLASSE"
  +
  +[NOTE.speaker]
  +--
  +* Listen statt einzelner Werte
  +* enums: weil wenn ich neue Werte schicke, kann ein Client darauf nicht reagieren und Fehler machen (z.B. 3. Klasse)
  +* Strings, wenn ich einen String als Basis nehme um daraus etwas abzuleiten, oder nach einem bestimmten Pattern parse
   --
   
   == Wie vermeide ich explizite Versionierung?
  
positive.code: * http://blog.restcase.com/restful-api-versioning-insights/
  * https://www.troyhunt.com/your-api-versioning-is-wrong-which-is/
  * http://www.oracle.com/technetwork/articles/web-services-versioning-094384.html
  
  
  
  
negative.code: 
  == Benötige ich explizite Versionierung?
  
  === Was spricht für explizite Serviceversionierung?
  
  [%step]
  * Hauptgrund: Konsumenten von Änderungen verschonen
  