API is sensitive to field ordred

I am developing integration for CircleK using Oracle SOA technology.

I have found, that API: https://selectapi.datascope.refinitiv.com/RestApi/v1/Extractions/ExtractWithNotes is sensitive to field order.

This is working:

{

"ExtractionRequest":

{ "@odata.type": "#DataScope.Select.Api.Extractions.ExtractionRequests.EndOfDayPricingExtractionRequest",

"ContentFieldNames": [

"Instrument ID",

"Instrument ID Type",

"Currency Code",

"High Price",

"Mid Price",

"Open Price",

"Trade Date",

"Universal Close Price",

"Close Price",

"Official Close Price",

"Previous Close Price",

"Exchange Code",

"Usage Instrument Type"

"IdentifierList": {

"@odata.type": "#DataScope.Select.Api.Extractions.ExtractionRequests.InstrumentIdentifierList",

"InstrumentIdentifiers": [

{ "Identifier": "PLNFIX=ST", "IdentifierType": "Ric" }

]

"Condition": null

}

But this not - gives HTTP 400:

{

"ExtractionRequest": {

"Condition": null,

"ContentFieldNames": [

"Instrument ID",

"Instrument ID Type",

"Currency Code",

"High Price",

"Mid Price",

"Open Price",

"Trade Date",

"Universal Close Price",

"Close Price",

"Official Close Price",

"Previous Close Price",

"Exchange Code",

"Usage Instrument Type"

"IdentifierList": {

"InstrumentIdentifiers": [

{

"IdentifierType": "Ric",

"Identifier": "USDFIX=ST"

}

"@odata.type": "#DataScope.Select.Api.Extractions.ExtractionRequests.InstrumentIdentifierList"

"@odata.type": "#DataScope.Select.Api.Extractions.ExtractionRequests.EndOfDayPricingExtractionRequest"

}

According to the REST messages and philosophy, both messages are equivalent.

Find more posts tagged with

dss

order

dss-rest-api

Accepted answers

Gurpreet

Hi @Agnieszka Kardas,

Yes, the OData type declaration is needed as the first line in the JSON request, or else the server is unable to process it. I am not sure if this is the part of OData specifications, or just a shortcoming on the DSS servers.

All comments

Gurpreet

Hi @Agnieszka Kardas,

Agnieszka Kardas

Hi @Gurpreet

Ok, but the problem is that REST API should not be sensitive to field order, because it is not the way how REST is working. In second message You've got all the informations and all the structure but in different order. So You should accept the message and parse it using the structure way not literal way.

If You need the proper structure, then it is not compatible to REST and try to use SOAP and WSDL contract instead. You have formal contract and formal structure.

Right now I can not go further with project because I am writing System 2 System integration and my system and libraries are changing order according to REST philosophy - structure is important, not the order.

Gurpreet

Yes, this has been raised previously. Unfortunately the Odata type declaration has to preceed any other data type.

See the response from the product team in this answer - https://community.developers.refinitiv.com/questions/14418/i-am-trying-to-run-some-tests-on-trth-v2-with-the.html

Agnieszka Kardas

Hi @Gurpreet

But, as mentioned in the link You provided, this is still a very bad behaviour, that has not been changed for 3 years and there is no concluding solution, or any feedback from Your development team. So I assume, this is still open.

If You can not fix this than provide me a SOAP API for Extractions/ExtractWithNotes functionality.

Gurpreet

Hi @Agnieszka Kardas, I recommend that you raise a product enhancement request ticket at my.refinitiv.com. This way the development team can directly hear from you and provide a suitable resolution.

zoya faberov

Hello @Agnieszka Kardas,

Allow me to clarify, "BAD REQUEST" is a standard error message that is returned by the service, to negatively acknowledge any request, that is not formatted as required by the service. This let the submitter know that the request as submitted is not valid, and will not be processed as expected.

It does not mean "bad behavior", and especially it does not mean very bad behavior by the service.

From what you are describing in the question, are you coding/creating your request and submitting to DSS, based on the contents of Oracle database table? If this is the case, are you defining a template/skeleton, that is static, and then, the instruments and fields of EOD request are populated from the table's contents dynamically? This design approach will allow you to proceed against OData Restful service implementation, and you may wish to review more on the approach in this article as well, perhaps re-use some of the code if you are integrating in python.

As a customer, you can submit a product enhancement request, as suggested by @Gurpreet , and it will be noted and prioritized by the product management.

Agnieszka Kardas

Hi @zoya faberov

No, I am not using any of this techniques. I am using Oracle SOA Middleware platform, that contains ready to use components. For example REST connection components. I am creating the message, as described in example, but I do not have control on what is happening later, because, as I have described and what REST ideology says - REST should be resistant to field order.

I have read the document that @Gurpreet provided to me with using of odata.type format and... maybe I am mistaken by I have not found a strict restrictions of using odata.type as first annotation in request. It says only, it must be.

If I need to use some "dirty Java hacking" than, from my perspective, I will recommend to move this project to Java dev team. It's easier to handle and manage in pure code than High Level Components.

zoya faberov

Hello @Agnieszka Kardas,

I hate to contradict, and especially, a customer,

But as I am looking at OData JSON Format documentation, I read:

" If present, the odata.context annotation MUST be the first property in the JSON object.

·The odata.type annotation, if present, MUST appear next in the JSON object.".

And with regard to the client integration: "Client libraries MUST retain the order of objects within an array in JSON responses".

So I am afraid that as implementation of the service is per OData JSON Format spec, the request requirement will have to be followed on the client side.

I would also, like you, hate any dirty java hacking. A solid design solution is certainly possible. I see some "OData client best practices" resources on the web, and I am hoping you'd be able to apply some of the suggestions to come up with an efficient design approach, perhaps in Java, perhaps in another language that supports HTTP REST and is synergetic to your overall solution design.

EXPLORE OUR SITES