Can OData be made to return CSV or URL? - json

I'm new to OData so I'm sorry if this is a bad question, but I fail to find an answer.
I have a bunch of OData tables, and I would like to provide an option for the user to get the data as a CSV-file.
Now I know OData only supports Atom and JSON, but is there any way to make it return a filestream, or a URL?
I was thinking a URL could direct to a REST-service (not OData) that simply returns a filestream, if filestream directly from OData is impossible.
Any thoughts or ideas are appreciated!

I'm not totaly sure why you want to use oData. But oData essentially means to publish any kind of data in JSON/atom standard format - not CSV.
If you have controll over your oData source you could modify an oData Producer to output CSV filestreams instead of JSON/atom files.(But you wouldn't have a real oData feed anymore)
You could also set up any oData Consumer (you can find those at odata.org) to read your oData source and display it as CSV.
If you choose a server side solution(PHP/JSP/ASP etc.) it should be rather simple to loop through the results of a request and add seperators inbetween.

Related

Request for example server side generated JSON for HPP integration

I'm trying to use a full page redirect with a direct integration and if I'm reading the documentation correctly I believe I should be able to generate the server side JSON to pass into RealexHpp.redirect. I know the code to generate this JSON is shared in a number of languages, but is the raw JSON output shared anywhere? I ask as the language I'm writing in isn't one of the ones covered, so I'm trying to make sure I get the output format correct.
I've tried re-creating the JSON structure based on what I believe the Java code displayed should output, but I'm obviously doing something wrong as its not working, would be really useful if I had some raw JSON to compare it against to make sure I'm getting the structure right.
Many thanks,
Raw JSON examples are not available, but we do have HTML POST examples (https://developer.globalpay.com/hpp/card-payments). You can build a JSON based on these.
This is how the JSON should look like: {"MERCHANT_ID":"MerchantId","ACCOUNT":"internet","ORDER_ID":"N6qsk4kYRZihmPrTXWYS6g","AMOUNT":"1999","CURRENCY":"EUR","TIMESTAMP":"20221121100715","AUTO_SETTLE_FLAG":"1","SHIPPING_CODE":"50001|Apartment 825","SHIPPING_CO":"US","HPP_SHIPPING_STREET1":"Apartment 825","HPP_SHIPPING_STREET2":"Complex 741","HPP_SHIPPING_STREET3":"House 963","HPP_SHIPPING_CITY":"Chicago","HPP_SHIPPING_STATE":"IL","HPP_SHIPPING_POSTALCODE":"50001","HPP_SHIPPING_COUNTRY":"840","BILLING_CODE":"59|123","BILLING_CO":"GB","HPP_BILLING_STREET1":"Flat 123","HPP_BILLING_STREET2":"House 456","HPP_BILLING_STREET3":"Unit 4","HPP_BILLING_CITY":"Halifax","HPP_BILLING_POSTALCODE":"W5 9HR","HPP_BILLING_COUNTRY":"826","HPP_CUSTOMER_EMAIL":"james.mason#example.com","HPP_CUSTOMER_PHONENUMBER_MOBILE":"44|07123456789","HPP_PHONE":"44|07123456789","HPP_ADDRESS_MATCH_INDICATOR":"FALSE","HPP_VERSION":"2","SHA1HASH":"308bb8dfbbfcc67c28d602d988ab104c3b08d012"}

Create JSON Object in React.js from Rest Service

I am looking for either guidance or a good example where I can map data coming from rest services to JSON "type" object which can then be used in a number of different react components.
The JSON Object will be used to map data from a few different rest services, which essentially hold very similar data which makes it better to use one object and then to bind the data to the respective React Components.
I am fairly new to React.JS and I have googled around to find a data mapper to JSON from Rest Service example.
Can anyone help?
You typically don't have to do too much, at least on the front end side. As long as the REST endpoint can return JSON responses you'll be fine. Just make sure you set the appropriate Content-Type headers in the request. Note that setting the header doesn't guarantee a JSON response, the server has to be able to send it in that format.
If you're creating the REST service yourself, you have many options. If you're using node, you can simply return a javascript object. If you're using some other language like Java, C#, etc., they come with libraries that can serialize objects into JSON for you. I use JSON.net when working with C#. In these cases, because the data will be returned as a string, you'll just need to JSON.parse() it upon receiving it and then set it to the appropriate React component's state.

How to query ASP.NET Web API like OData, but with a POSTed JSON object, not a GET URL/QueryString?

How to query ASP.NET Web API, but with a JSON POST, not GET URL?
The JSON object would contain the same data/filters/sort/paging as ODATA query or LINQ query. Can we deserialize the JSON object into something ODATA/LINQ can understand and then use that to easily execute on the DB (SQL Server)?
We've come across from articles about LINQ Expression Trees and ODataLib ODataUriParser, but still researching.
We want to expose an advanced search web service for a few tables or views in SQL Server, and want to keep it JSON and generic so many platforms can consume it. The consumer would need to pass in the search parameters, and we could probably create a data structure to contain it all, but are trying to also see if we can leverage some query model in ODATA or LINQ.
Any way to instead of putting the OData query in the URL, put it as a POSTed JSON object instead and have it continue to query the DB and return results normally? A couple of current reasons to put in POST are 1. can handle larger size and 2. instead of the consumer learning OData query syntax, they can just popular an search param object model.
Thanks in advance.

Best practices to produce JSON from NotesViews or DocumentCollections

I'm working on a custom control that will be fed by JSON content and I'm trying to find the best approach to produce and consume it.
Let say the JSON could be from:
Notes View (all documents)
Notes View (subset of documents based on a category or filter)
Notes Document Collection (from database.Search or database.FTSearch)
What I have on my mind is to define some Custom Properties where I can define:
URL that produces the JSON
Object
etc.
So far I'm considering:
REST Service control from ExtLib
XAgent that produces JSON
Domino URL ?ReadViewEntries and OutputFormat=JSON
Does anyone knows if the JSON object loaded in memory has a size limit?
Any suggestion will be appreciated.
Definitely go for the REST Service control from the Extension Library, offers by far the best combination of flexibility vs performance vs development time.
Matt
What about creating the JSON in the view itself and then just read the column values? http://www.eknori.de/2011-07-23/formula-magic/
If you want to parse the json object using ssjs, you can fetch it using an URLConnection and put the resulting object into a repeat control using the eval statement.

How to disable content negotiation and always return JSON from WCF data service?

Let's say I have a northwind database and I use ADO.NET Entity Data Model which I automatically generate from the tables in database. Then I add a new WCF data service that inherits from DataService. When I start the web application, that runs the service I can request data like this:
http://machine/Northwind.svc/Orders
This will return all orders from order table in atom/xml format. The problem is I do not want XML. I want JSON. I think I tried all kinds of settings (web.config) and attributes in my application, but I still get XML. No matter what. I can only get JSON, when I use fiddler and change the request header to accept JSON.
I do not like the concept of content negotiation. I want always to return data in JSON format. How can I achieve that?
Keep in mind that I did not create any model objects, they are automatically created based on database tables and relationships.
Well - content negotiation comes with HTTP. In any case, you could intercept the incoming request and add/overwrite the Accept header to always specify the JSON. There's a sample how to support JSONP which uses a similar trick, I think you should be able to modify it to always return JSON as well. http://archive.msdn.microsoft.com/DataServicesJSONP.
The behavior you criticize is defined by specification of OData protocol. OData defaults to Atom and client can control media type of the representation either by Accept HTTP header or by $format parameter in query string (but I'm not sure if WCF Data services already support this).