This section contains the following topics:
Standards Compliance
The WS API is implemented to comply with the following standard specifications:
Standard Name | Website |
Simple Object Access Protocol (SOAP) 1.1 | http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ |
Web Service Description Language (WSDL) 1.1 | http://www.w3.org/TR/2001/NOTE-wsdl-20010315 |
Development Platforms
The API has been validated to work with J2EE 1.6 and Apache Axis2 development environments. In this document, we provide examples in Java. The Java examples are based on Apache Axis2 1.5.1 and JDK 1.6. For more information, see http://axis.apache.org/axis2/java/core/.
API Support Policy
We recommend that your new client applications use the most recent version of the Service Desk WSDL file to exploit the benefits of richer features and greater efficiency. You can fetch the most recent WSDL by accessing the Service Desk Web Services URL.
For example, you can obtain the Service Request WSDL by going to this URL- https:// {servicedeskcontexturl} /NimsoftServiceDesk/servicedesk/webservices/ServiceRequest?wsdl. In this example, the {servicedeskcontexturl} is your adjusted login URL. To identify the adjusted login URL for your instance, consider the following examples:
- You are a user that accesses CSM1 or CSMStaging. Typically, you log in to https://csm1.serviceaide.com. To access the Service Request WSDL, you can access one of the following URLs:
Note: The exact URL depends on the instance that you are accessing. Contact the support team for the exact URL, or use the provided example to construct the URL.
When a newer version of Web Services is released, follow these steps to regenerate the client code from an existing WSDL document:
Regenerate the client stubs using WSDL2JAVA utility.
- Update Client Class from existing/latest version of WSDL document.
- Compile & Run the Client Class.
Backward Compatibility
ServiceAide Cloud Service Management does not ensure that an application written against one WS API version works with future API versions. Changes in method signatures and data representations are often required as we continue to enhance the API.
However, we strive to keep the API consistent with previous versions. This approach helps to ensure that you can port applications to newer versions of the API with minimal changes.
0 Comments