我想从Acumatica实例中将库存项目作为数据合同导出，但不调用API。我不想调用API，因为我需要从实例内部而不是实例外部检索它。我认为我真正需要的是一种调用基于合同的代码以序列化为JSON的方式，但无需使用URL。我想我可以在同一实例中调用该API，但似乎比这更容易。
答案 0 :(得分：0)
严格来说，您要进行API调用。特别是使用“基于合同的API”而不使用“ Web服务API”。这似乎违反了基于合同的API的设计目标。
请考虑以下语句： 基于合同的API建立在Web服务API提供的对象模型上。 资源： https://adn.acumatica.com/blog/yes-we-have-an-api-for-that-an-introduction-to-the-acumatica-cloud-erp-apis/
Web服务API提供了基于合同的API的对象模型。删除方程式的Web服务API，并且基于合同的API缺少对象序列化所依赖的对象模型。实际上，这意味着处理基于契约的序列化的方法将需要Web服务对象模型作为输入参数。
我认为，在不使用TCP-IP堆栈的情况下，阻止Web服务对象模型的实例化将存在多个技术障碍。这主要是因为基于合同的API的原始设计目标是通过Web服务调用的。
这归结为Acumatica，它针对不同的上下文使用不同的对象模型。基于合同的使用“实体”模型，而自定义的使用“ DAC”模型。查询API也有很大的不同。使用BQL进行定制和基于合同的定制还有其他方法。
拥有统一的对象模型有明显的优势。学习只使用一种比必须学习两种更容易。独家使用JSON比混合和转换XML和JSON更容易。但是，每种模型也都有其缺点。使用不同的模型可以使用更适合手头任务的模型。对象模型的常见要求是性能，人类可读性，内存占用量，易于机器解析的能力等。
这就是说，如果您只需要没有查询接口的基于合约的API的对象模型，则可以使用BQL并将DAC对象序列化为JSON来近似它。因为几乎所有DAC对象都具有C＃可序列化属性，所以与使用数据合同API来检索和序列化记录而不通过TCP-IP堆栈相比，对使用BQL检索的DAC对象进行序列化应该容易得多。它也将朝着API设计目标的方向发展，即应将基于合同的API用于通过Web服务进行访问。