Feedback on Custom Object API

[Nawksen]

First of all, we (I-Centrum) loves that you are building the Custom Objects API, since that really gives us the possibility to convert some of our adaptable solutions into real apps, so kudos on that.

But, we do not agree with the encoded values since it will (and already are) creating alot of headaches.
Lets take this as an example:
{ "Id": [I:1], "Name": "x_equipment_id", "Type": "int", "DisplayName": "Something", "Description": "This is a new description", "UseDefaultValue": [I:1], "DefaultValue": "This uses default value", "Rank": [I:1] }
This is not a valid Json due to [I:1], so no auto parser will ever be able to handle it, and even if you send along "[I:1]" it still needs alot of work to be able to process.

Since we need to check each field, and lets say you have 100, if it is an encoded value, and if it is, detect what type it is, and based on that, get the actual value.
This seems like an extremely ancient way of building an REST API instead of just sending the actual data.

So, for example in c#, how we usually setup a model/controller that needs to handle a json.
We get the actual JSON with values, we create a modal and in Visual studio code we just paste it as Json, then visual studio auto detects what kind of data it is and automatically builds the model for us.

In this case with the encoded values, we need to treat everything as a string and build functions to actually identify the data, it does not really make any sense for a modern API.

ps. this of course also applies to TypeScript, where crmscript returns the actual data but typescript returns the encoded value and it just makes coding alot less fun.

[SuperOfficeDevNet]

Thank you so much for taking the time to share your feedback — we truly appreciate it.

You were absolutely right to point out the typos and formatting issues in the JSON responses. We’ve corrected those in the proposal. In our APIs, input values are always used in their native format, while all responses are encoded as strings.

We completely understand your perspective that responses shouldn’t need to include encoded values. This idea has come up before, and suggestions like using a header or another mechanism to indicate this are definitely on our radar for future consideration.

Thanks again for helping us make things better.

Warm regards,

SuperOffice DX Team