It would be great to have some consistency between versions of the API. When moving from one version to the next, the interface should be as consistent as possible to the previous version to minimise the imapct on applications consuming the APIs. Also, the API functionality should be consistent. For example, the version 1 contacts batch APIs appear to execute the batch and report individual errors in the response but the version 3 contacts batch APIs return only a single ID. There are pros and cons with each method but if the API changes behaviour between versions then this needs to be documented and, preferably, old behaviour should be switchable so that the API user can choose which methodology they need. In my case, using v3 of the APIs, I now need to iterate through all items in a batch, after an error, to re-try each individual item and ascertain which other items fail so for me, the v1 API method was preferable. The v1 API method is better in my case, but then I lose the advantages of the improved performance and flexibility of the v3 API. In addition, providing consistent endpoint URLs would also improve the useability of the APIs. I'm developing a generic synchronisation process which is driven by queries into our databases. The queries return object types and attributes to be passed to HS. The issue is that, because the endpoints differ between objects, I need to hard-code object types in the middleware. For example, the contacts and companies enpoints begin with /crm/v3/objects/object-type/ so I can simply inject the object type into the URL based on the data returned from the databases. The v3 asssosications APIs break this model though, ommitting the objects keyword from the URL (/crm/v3/associations). Interestingly, the v4 associations API moves more towards the contacts / companies model of including objects in the URL. Having standardised endpoint structures would greatly enhance the ability to write generaic applications which utilise the APIs.
... Afficher plus