Why am I getting XML results from the Exact Online API where I used to get JSON results? - exact-online

Just started working on an existing project making use of the Exact Online API.
While I was debugging the project I suddenly only started receiving XML results instead of JSON results from the API. I did not change anything about the endpoints being queried I was just running the existing queries trying to figure some things out.
These are the REST API docs: https://start.exactonline.nl/docs/HlpRestAPIResources.aspx
These are the XML docs: https://support.exactonline.com/community/s/knowledge-base#All-All-DNO-Content-xmlsamplecode
Typical REST API endpoints look like this:
https://start.exactonline.be/api/v1/xxxxxx/salesinvoice/SalesInvoices
Typical XML endpoints look like this:
https://start.exactonline.be/docs/XMLDownload.aspx
I also did not change any settings. I only have access to the tokens and api. I don't have access to the account.
This is an example of an endpoint and query where I previously received JSON but am now receiving XML:
https://start.exactonline.be/api/v1/xxxxxx/salesinvoice/SalesInvoices?$filter=InvoiceID eq guid'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx'&$select=InvoiceID
I tried this manually with Postman and also using the existing code from the project.
Is there some setting I am unaware of? Am i querying the wrong way? Maybe there have been some changes to the API I am unaware of that aren't listed in the release notes?

Please provide the request header Accept in your HTTP request that specifies what content format you prefer to receive: application/json. The default of Exact Online APIs is XML (but seldom to never used).

Related

Dynamic 365 API only returns XML despite Request for JSON

I am using Postman to query a Dynamics 365 Business Central (BC) API. The API is returning XML and I am trying to get it to return JSON. The Microsoft page that gives an example shows the response as being in JSON format.
I tried added my own Request header to denote that I would like JSON returned
Postman says that by adding my own "Accept" Request header it will override the one that is auto-generated
Even so I tried sending the request with the auto-generated "Accept" header disabled and enabled. This is the response ...
Am I requesting JSON the proper way for a REST endpoint? Microsoft's example seems to indicate that JSON can be returned yet I am only able to get XML back as shown below (just a fragment)
There are two different endpoints you are talking about, $metadata which generates the whole CSDL schema in xml format, whereas <endpoint>/companies fetches the data in JSON format.
This can be tested in browser simply pasting these URLs.
https://api.businesscentral.dynamics.com/v2.0/environment name/api/v2.0/$metadata
https://api.businesscentral.dynamics.com/v2.0/environment name/api/v2.0/companies
Note: Pls test it. I don’t have experience with Dynamics BC, but I managed to get these from docs with the idea of my Dynamics CRM experience :)
Correct me if I am wrong. But microsoft dynamics uses both SOAP and Rest call, seems like you need to use Dynamics Odata APIs
You can go through this doc to understand dynamics Odata APIs :- https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/data-entities/odata

iTunes Store Customer Reviews API XML Endpoint Broken

I used to use the XML endpoint because it provided review dates for each review called 'updated'. This is not contained in the JSON endpoint. However, the XML endpoint stopped working. I get the error seen below:
Web Server Error
Description: The host did not return the document correctly.
Has anyone experienced the same issue? Any workarounds? Do you anticipate this will ever be fixed by Apple? Do you think the JSON endpoint might be taken down any time soon?
XML Endpoint (Broken)
https://itunes.apple.com/us/rss/customerreviews/id=1145275343/mostrecent/xml
JSON Endpoint (Working)
https://itunes.apple.com/us/rss/customerreviews/id=1145275343/mostrecent/json
It appears the XML endpoint is up and running again. No more Web Server Error. Hopefully the endpoint stays up.

Apache Nifi, how to get JSON from API

I've started using Apache Nifi and I'm still learning it and experimenting with it. I really want to use Nifi to get JSON documents from API's and put them in my Elasticsearch database. So far using the built-in getTwitter and putElasticsearch controllers this works.
However now I want to do this with other APIs than Twitter, and I'm kinda stuck here. First off I really don't even know which controller to use? I would think getHttp or invokeHttp even with 'GET' as http verb then but it doesn't seem to work. If I use the getHttp I have to give an SSL service with keystore and truststore .. like why would I have to do that?
Apache Nifi is still quite new so hard to find decent guides / information about these kinds of things. I have read and searched the documentation but haven't gotten the wiser.
An example JSON to pick up from an API is:
https://api.ssllabs.com/api/v2/getEndpointData?host=www.bnpparibasfortis.be&s=193.58.4.82
Thanks in advance for anyone that can offer some help / insight.
What processor you use to get the JSON data is entirely dependent on the API you want to hit. The GetHttp or InvokeHttp processors should work to grab the data from a URL. If you'll notice, the SSL service is an optional property for both GetHttp and InvokeHttp so you only need to you use it when you want to communicate via HTTPS. Also, from the UI you can right click on a processor and then click "usage" to bring up the documentation for that processor.
At this link[1] you can find a NiFi template that uses GetHttp to get JSON data from randomuser.me and does various processing on it. It's primarily a template to show-case the different Avro processors but the method of grabbing the JSON should be relevant.
[1] https://github.com/hortonworks-gallery/nifi-templates/blob/master/templates/Convert_To_Avro_From_CSV_and_JSON.xml

WSo2 API Manager 1.8.0 - JSON parsing issue

I am new to wso2 API Manager, trying to set it up expose my plain HTTP POST back end calls as a REST API. I am sure this is not a new pattern that I am trying to achieve here. The requirement is to convert the JSON data coming in (has array structures) into the HTTP URL query string parameters.
After some research through the documentation and other posts on this forum, decided to go with the script mediator that would parse the JSON data and convert it to a string that can be appended to the endpoint URL. Some how I am not able to achieve this.
I have followed the following post that seems to be very straight forward. As the original poster suggested, I am also not able to use getPayloadJSON() method. Even have trouble using the work around suggested there due to JSON.parse() not working.
Link
Also, this approach of editing the service bus configuration from source view does not sound like the correct option. Is there another elegant solution to achieve this? Thanks for the help in advance.
I was able to get both methods working by using an external script instead of the inline java script. Thanks

REST Service testing - SOAP UI

I need to add JSON format parameters to request payload to do a POST request in restful service testing. How can I do that in SOAP UI?
You did not specify which version of SoapUI you are using. In version 4.x of SoapUI, they made the same assumption as what FrAn answered: you generally do not want to include a payload for a GET request. In later versions of SoapUI, they corrected this and you are able to do it.
Once you change the method type to POST, on the individual method call, you will see another panel where you are able to define the body. You can see this in the documentation. You will have to write out the entire body manually.
For REST services, the payload is not part of the WADL - which SoapUI uses internally to store the entire definition. You can create a sample Request in your REST service to make creating test cases easier. You can see this in the documentation.
Lastly, some additional information is available in the API Dojo.
HTTP GET request shouldn't contain payload. While you can do that, insofar as it isn't explicitly precluded by the HTTP specification, I would suggest avoiding it simply because people don't expect things to work that way.