Larry O' Brien has some notes on programming against the Sabre GDS.  Most of what Larry says applies to other GDS systems (Apollo/Galileo, Worldspan, and Amadeus), though it's interesting to hear bits about Sabre's specific implementation.  Larry mentions abandoning OO purity, specifically mentioning the concept of "Flight".  Many development teams have come to grief on this concept, not even to the extent of confusing a "Flight" with a physical airplane, but with simply getting an incorrect perception of what the data comprising a Flight means and what can be done with it (for starters, it's read-only and parts of it are subject to change at any time).  I'm a little puzzled by Larry's assertion that Sabre's concept of a flight is Carrier + Flight Number, but not the date; I've found that Carrier, Flight Number, and Date to be a good proxy for identity in this case.  Speaking of dates and times, a GDS' idea of time generally doesn't include a time zone; rather, time is assumed to be the local time in the city you're referring to.  So if a flight is scheduled to leave JFK at 10 AM and arrive in Denver at 12 noon, those times are local, so the actual duration of the flight is 4 hours.  Beware of trying to convert times into, say, java.util.Date - you can end up with incorrect assumptions about time zone. 

As far as Larry's comments on TA configuration, inconsistent error responses, and  limits on group sizes, let's just say that after working with a GDS for a while, the law of leaky abstractions will make its power felt in novel ways.  The inconsistent error responses are a great example.  What a GDS does, primarily, is aggregate data from other vendors' systems: airlines, car rental companies, hoteliers, tour operators, cruise lines, etc.  In the Apollo and Galileo systems, for instance, you can get errors from a "front end" system (generally communications related), from the "core" system, or from a "link vendor", i.e. some remote system that you weren't necessarily aware that you were talking to.  The GDS usually does pretty well at hiding the link on the inbound side (submitting a transaction) but in the event of an error, tends to punt the message straight back to the client.