Diskussion:Release 0.4: Unterschied zwischen den Versionen

Aus DRV STRING
Wechseln zu: Navigation, Suche
(First impressions of prorgamming with the API.)
 
 
(2 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 10: Zeile 10:
 
** It just causes names to be longer without any additional information.
 
** It just causes names to be longer without any additional information.
 
** It makes code completion features in IDEs difficult to use, if everything starts with "String...".
 
** It makes code completion features in IDEs difficult to use, if everything starts with "String...".
 +
* The same argument applies for the suffix "Type" on many types.
 +
** We should remove this, too.
 +
** Example "StringBookingResponseType" -> "BookingResponse"
 
* Maybe we can get rid of redundant collection containers, i.e. if we have a ''<services/>'' element we do not need a ''<service/>'' element below that which in turn contains the concrete element ''<Accommodation/>'' . We should eliminate the generic ''<service/>'' element in between:
 
* Maybe we can get rid of redundant collection containers, i.e. if we have a ''<services/>'' element we do not need a ''<service/>'' element below that which in turn contains the concrete element ''<Accommodation/>'' . We should eliminate the generic ''<service/>'' element in between:
  
Zeile 34: Zeile 37:
 
     </ns2:Services>
 
     </ns2:Services>
 
</pre>
 
</pre>
 +
 +
<hr>
 +
I (bachemj) agree to the removal of String* and *Type of type names as they indeed are redundant.
 +
 +
(pholtermann): I also still think the name "String" for the project is problematic. IMHO the association with the programming data type "String" is to strong. (An alternative name could be '''T'''ravel '''A'''pplications '''N'''ext '''G'''eneration '''A'''PI :)

Aktuelle Version vom 30. März 2017, 14:04 Uhr

To get a feel for the API I created a temporary WSDL with two operations "quote" and "book". From this I created a dummy java web application (WAR) using "wsimport" and played around with it a little.

Here are my first impressions and suggestions:

  • Generation of code works fine with only one little problem:
    • There are a few abstract types in the definitions, e.g. "StringCommonTravellerType". This prevented travellers to be created from the input xml request at runtime.
    • So for the time being, I removed all four "abstract=true" statements in my local copy of the xsds. We should look into this.
  • We should get rid of the "String"-Prefix of every type name.
    • It just causes names to be longer without any additional information.
    • It makes code completion features in IDEs difficult to use, if everything starts with "String...".
  • The same argument applies for the suffix "Type" on many types.
    • We should remove this, too.
    • Example "StringBookingResponseType" -> "BookingResponse"
  • Maybe we can get rid of redundant collection containers, i.e. if we have a <services/> element we do not need a <service/> element below that which in turn contains the concrete element <Accommodation/> . We should eliminate the generic <service/> element in between:

Currently we have to write:

    <ns2:Services>
       <ns2:Service>
          <ns2:Accommodation>
             <ns2:Identifier>DUMMY_TEST_RESULT</ns2:Identifier>
             <ns2:EndDate xsi:nil="true" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
             <ns2:Stay xsi:nil="true" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
          </ns2:Accommodation>
       </ns2:Service>
    </ns2:Services>

Which could be written more concise as:

    <ns2:Services>
          <ns2:Accommodation>
             <ns2:Identifier>DUMMY_TEST_RESULT</ns2:Identifier>
             <ns2:EndDate xsi:nil="true" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
             <ns2:Stay xsi:nil="true" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
          </ns2:Accommodation>
    </ns2:Services>

I (bachemj) agree to the removal of String* and *Type of type names as they indeed are redundant.

(pholtermann): I also still think the name "String" for the project is problematic. IMHO the association with the programming data type "String" is to strong. (An alternative name could be Travel Applications Next Generation API :)