10-17-2017 08:46 AM
In my experience, a solid REST API denotes success/failure via HTTP status code, and the response contains a represnetation of the created/modified object's new state.
The Zuora REST API's various endpoints return inconsistent data structures, none of which directly rerpesent the object which was acted upon.
Specifically, I'd love to see the CRUD endpoints denote creation/update success via an HTTP status code in the 200 range, remove the `success` property of the response body, and return all current properties of the newly created/updated object.
As is, I have to POST data for object creation, then use the ID that was returned to GET an actual representation of the created object. This is, as I said, rather non-standard and a waste of API calls and processing time.
10-17-2017 09:16 AM
The issue raised here definitely has caused us difficulties modeling data in our use of the API. If we relied on HTTP response status codes instead of arbitrary fields in the response, and also received the full object in the response - we'd save API calls (i.e., time) and have a much-closer-to-RESTful API.
10-18-2017 10:51 AM - last edited Friday
This is a fair note. Please note that we are slowly transitioning to truly REST-ful API's, and in the interim, we've chosen to provide 100% REST coverage of our API's, with the downside of some of the API's not being truly REST-ful. Specifically, when you are working with any endpoints that begin with /v1/action or /v1/object, you'll get the same response as we provided with SOAP. All other endpoints should be REST-ful. Bear with us as we re-design all of our API's over time.
Also, some API endpoints return 'Success', and some return 'success'. Here are examples of working code that illustrates this:
response = self._post('/object/export/', payload) assert response['Success'], response
response = self._delete('/object/export/' + object_id) assert response['success']
Thanks for the reply, @lukasz! It is difficult for us, especially as Zuora has directed everyone to start using REST as opposed to SOAP, but I certainly understand the size of the job. Your note explaining that SOAP is currently fully covered under the new API system is helpful, and explains a lot!