DealerRater for Developers

Architecture

The DealerRater API has been designed around a pseudo-REST based architecture. For developers familiar with strict REST design paradigms, you'll find most of what you see here familiar, but there are a few deviations from what you might be familiar with. Namely:
  • We don't use standard verbs with our requests. We use GET, INSERT, UPDATE and DELETE instead of GET, PUT, POST and DELETE.
  • The verbs you post to the website are defined in a common "method" request parameter, not the HTTP verb itself. The actual HTTP call you make can use GET or POST (our server will accept either). If no "method" parameter is passed, GET is the default.
  • Server status is not indicated via the response status code on the API. The server always returns a successful response, with the call status indicated within the response body.
Each API that is listed on the main documentation page identifies a unique endpoint that allows you to fetch or manipulate data on the server. Each endpoint is identified as a Collection API (an API that allows you to manipulate more than one thing) or an Entity API (an API that only allows you to manipulate a single thing). Each unique API also allows for the use of at least one REST verb. The verb identifies what you want to "do" -- are you looking to fetch data, update data, create data or delete data? Not all APIs support all verbs, but every API supports at least one verb. The verbs you should become familiar with are listed below:

Verb Description
GET Use this verb to fetch/load data from the server.
INSERT Use this verb to create (or insert) new data into the server.
UPDATE Use this verb to update (or modify) data that already exists in the server.
DELETE Use this verb to delete data from the server.

Sending and Receiving Data

Each REST API is capable of sending and receiving data. Every REST API call supports some number of request parameters, which are documented on each REST API page. In addition, certain APIs will accept request data in the form of XML or JSON. APIs that accept this data expect the data to come in a post with the JSON or XML in the "data" request parameter. Each API call will also send back data to the client in XML or JSON format. Each REST API is responsible for documenting all the request and response behavior.

Future changes to the API

The API will undoubtedly evolve over time. We will make every effort not to modify the XML and JSON responses in such a way as to break your integration. This primarily would involve complete removal or modification of one of the element or attribute names. Your integration should, however, accept new JSON attributes and XML elements in the data you consume from the API without failing.