GM API

##Gaps and Potential Issues

• Current tests take ~20 seconds to provide a response for any vehicle command (unlock, start, horn, etc.). We need some advice from GM to confirm if this is what we should expect in a production-like environment. This is a potential showstopper!
• Based on the GM documentation, the 2015 Chevy Spark EV does not support Remote Start/Stop features.
• Chevy Spark EV is not available in the sandbox for testing.
• Have failed to obtain Location information via any of the vehicles in the sandbox (even though the command should be supported).
• Known to have limitations when car is near tall buildings, hills, tunnels, or there is bad weather. (the GM documentation details the limitations, but users of the OnStar App in the App Store have suggested that the diagnostics is not accurate and that cars did not response to commands like unlock when in bad weather).
• Suggests we need to go through a GM Approval process and submit apps. Confirm if this is required for us.

--

##Documentation The documentation for the API can be found here.

##Overview The API uses REST for the communication. A full description of error codes and URLs can be found there also the API is described on 5.1 and 5.3 of the API guide.

##Structure The way the API works all the vehicles are tied to one account, so on production all vehicles of waivecar will be tied to the account that we use to access the data.

##API Request All api requests can be paginated, The request must be either in XML or JSON format. To get the required format of the response the client can specify the MIME type in the Accept Type HTTP header as application/json or application/xml.

pay attention to this: The JSON format that is used in this API will return multiple instances of an item as an array. However, if there is only a single element it will be returned as a object or a single value.

###Asynchronous Requests Some requests are asynchronous the way that this works is:

• Upon request you will receive a 202 HTTP reader, this indicate that the response is asynchronous with a commapdResponse with the status inProgress

• On the response there will be a command response with a url that will be used for polling;

• You can request the polling every 5 seconds no less than that;

• If the request was successful you'll receive a HTTP 200 with a body of CommandResponse with status attribute set to completed.

• If the request fails a HTTP 200 will be send with a CommandResponse with status attribute set to failure.

###Client errors Client errors will always result in HTTP response code with a 4XX series code and no body content as the response codes are self-explanatory.

###Server errrors Unsuccessful invocations due to Server error are returned with 500 (“Internal Server Error”). This response will contain a body further detailing the error.

In some cases the server may need to provide more information via a ‘moreInfo’ URL. Below is one such example in XML.

###Security All communications with the server must be done over HTTPS.

###About usage. Some apis must be used on the exact way that they were described, for example the alert api requires always the override options with values, all requests that extend BaseRequestType requires delay and so on.