locked
Does OData Data Source Connection Support JSON Format?

Answers

  • To be clear: we are talking about what format the LightSwitch middle tier uses to talk to an attached OData service.  Why does it matter what format the middle tier uses to talk to the backend OData service?  If the backend OData services doesn't support Atom, then it isn't a fully functioning OData service and isn't supported by LightSwitch.

    To answer your question Garth, there is no workaround.  LightSwitch uses the .Net "WCF Data Services" DataServiceContext class http://msdn.microsoft.com/en-us/library/system.data.services.client.dataservicecontext.aspx to communicate with the backend OData service.  WCF Data Services' .Net client does not allow specfying the format to use to talk to the OData service.  It always uses Atom in the current release.

    However, on the other side of the coin, if you are writing a non-LightSwitch client that wants to use the JSON format to communicate with the LightSwitch middle tier, then you just need to set the accept header, as outlined here: http://www.odata.org/developers/protocols/operations

    "OData supports two formats for representing resources, the XML-based Atom format and the JSON format. As described in the HTTP specification [RFC2616], clients can indicate their preference of resource representation by including an accept request header with a list of MIME types it can handle.

          A client that wants only JSON responses would set this header to "application/json".      For example:

    GET /OData/OData.svc/Products HTTP/1.1 host: services.odata.org accept: application/json

    Friday, March 9, 2012 4:51 PM
    Moderator

All replies

  • We absolutely require an OData feed to implement $metadata and to have a valid service root which lists the available entity sets.  We can not infer a full fidelity model from entity data alone, irrespective of what format it is in.

    Thursday, March 8, 2012 4:40 PM
  • The Attach Data Source Wizard only supports a functioning OData endpoint.  For it to be a functioning OData endpoint, it needs to support $metadata requests.  Also, a functioning OData endpoint should also support returning both Atom and JSON formats, as requested by the client.

    That being said, in Visual Studio 11 Beta, the Attach Data Source Wizard only ever requests Atom format.  The OData endpoint should respect what the client requests, in this case Atom.  If the Wizard requests Atom and the service returns JSON, then the Wizard is going to have a problem because it is expecting the response to be in the Atom format.

    So the short answer is, for Beta the Attached Data Source Wizard only uses Atom format.

    Thursday, March 8, 2012 8:59 PM
    Moderator
  • Eric,

    Please, what is the work around to use the JSON format with the current beta?


    Garth Henderson - Vanguard Business Technology

    Friday, March 9, 2012 2:06 AM
  • I believe the data source you linked uses Socrata Open Data API and not OData, so it won't work even though it does support xml ( http://data.edmonton.ca/api/views/5zeu-wkpv/rows.xml ... see more info at http://data.edmonton.ca/api/docs/ )

    Friday, March 9, 2012 1:50 PM
  • To be clear: we are talking about what format the LightSwitch middle tier uses to talk to an attached OData service.  Why does it matter what format the middle tier uses to talk to the backend OData service?  If the backend OData services doesn't support Atom, then it isn't a fully functioning OData service and isn't supported by LightSwitch.

    To answer your question Garth, there is no workaround.  LightSwitch uses the .Net "WCF Data Services" DataServiceContext class http://msdn.microsoft.com/en-us/library/system.data.services.client.dataservicecontext.aspx to communicate with the backend OData service.  WCF Data Services' .Net client does not allow specfying the format to use to talk to the OData service.  It always uses Atom in the current release.

    However, on the other side of the coin, if you are writing a non-LightSwitch client that wants to use the JSON format to communicate with the LightSwitch middle tier, then you just need to set the accept header, as outlined here: http://www.odata.org/developers/protocols/operations

    "OData supports two formats for representing resources, the XML-based Atom format and the JSON format. As described in the HTTP specification [RFC2616], clients can indicate their preference of resource representation by including an accept request header with a list of MIME types it can handle.

          A client that wants only JSON responses would set this header to "application/json".      For example:

    GET /OData/OData.svc/Products HTTP/1.1 host: services.odata.org accept: application/json

    Friday, March 9, 2012 4:51 PM
    Moderator
  • To be clear: we are talking about what format the LightSwitch middle tier uses to talk to an attached OData service.  Why does it matter what format the middle tier uses to talk to the backend OData service?  If the backend OData services doesn't support Atom, then it isn't a fully functioning OData service and isn't supported by LightSwitch.

    To answer your question Garth, there is no workaround.  LightSwitch uses the .Net "WCF Data Services" DataServiceContext class http://msdn.microsoft.com/en-us/library/system.data.services.client.dataservicecontext.aspx to communicate with the backend OData service.  WCF Data Services' .Net client does not allow specfying the format to use to talk to the OData service.  It always uses Atom in the current release.

    However, on the other side of the coin, if you are writing a non-LightSwitch client that wants to use the JSON format to communicate with the LightSwitch middle tier, then you just need to set the accept header, as outlined here: http://www.odata.org/developers/protocols/operations

    "OData supports two formats for representing resources, the XML-based Atom format and the JSON format. As described in the HTTP specification [RFC2616], clients can indicate their preference of resource representation by including an accept request header with a list of MIME types it can handle.

          A client that wants only JSON responses would set this header to "application/json".      For example:

    GET /OData/OData.svc/Products HTTP/1.1 host: services.odata.org accept: application/json


    I know the LightSwitch Team has articles scheduled to cover this, but ANY code examples of JSON communication you can share now would be very helpful.

    Make Them Ask: That's a LightSwitch App?

    http://LightSwitchHelpWebsite.com


    Friday, March 9, 2012 5:14 PM
  • I would recommend using a framework that is already developed for communicating with OData instead of writing your own framework and parsing logic.  Take a look at the client libraries listed here:

    http://www.odata.org/developers/odata-sdk

    I know the datajs Javascript library uses JSON.  I'm not certain on the others.  The current .Net SDK shipped by Microsoft doesn't support JSON, like I said above.

    Friday, March 9, 2012 7:06 PM
    Moderator
  • I would recommend using a framework that is already developed for communicating with OData instead of writing your own framework and parsing logic.  Take a look at the client libraries listed here:

    http://www.odata.org/developers/odata-sdk

    I know the datajs Javascript library uses JSON.  I'm not certain on the others.  The current .Net SDK shipped by Microsoft doesn't support JSON, like I said above.


    Thank You

    Following that clue, this link appears to be ths hot ticket:

    http://www.kashyapas.com/2011/06/05/performing-crud-on-odata-service-using-datajs/

    Make Them Ask: That's a LightSwitch App?

    http://LightSwitchHelpWebsite.com


    Friday, March 9, 2012 7:39 PM
  • To answer your question Garth, there is no workaround.  LightSwitch uses the .Net "WCF Data Services" DataServiceContext class http://msdn.microsoft.com/en-us/library/system.data.services.client.dataservicecontext.aspx to communicate with the backend OData service.  WCF Data Services' .Net client does not allow specfying the format to use to talk to the OData service.  It always uses Atom in the current release.

    However, on the other side of the coin, if you are writing a non-LightSwitch client that wants to use the JSON format to communicate with the LightSwitch middle tier, then you just need to set the accept header, as outlined here: http://www.odata.org/developers/protocols/operations

    "OData supports two formats for representing resources, the XML-based Atom format and the JSON format. As described in the HTTP specification [RFC2616], clients can indicate their preference of resource representation by including an accept request header with a list of MIME types it can handle.

          A client that wants only JSON responses would set this header to "application/json".      For example:

    GET /OData/OData.svc/Products HTTP/1.1 host: services.odata.org accept: application/json

    Eric, thanks sooo much for this clarification and direction.

    What is the best approach to build "universal platform" web sites (that run on all browsers, pads, phones supporting HTML5/JS) using the LS OData middle tier?

    LS handles forms and complex biz apps just fine.   However, it is a requirement that our biz apps integrate with web pages and our clients have a web page design management system that will work best with LS.

    For example, can we (or . . . should we) use DNN, Umbraco (MVC), or WordPress (PHP) technology with our LS apps?  What is the best direction?  

    My boss has asked me to get an answer on this in light (all puns intended) of the v2 release the the 2012 MS technology stack.

    To be clear, our LS applications support niche industries.  The businesses that use our LS applications need to build and maintain web sites for marketing, sales, customer support, and partner business integration. These web sites must run on all devices with HTML5/JS technology.  What is the best technology to use in partnership with LS?


    Garth Henderson - Vanguard Business Technology

    Friday, March 9, 2012 8:54 PM
  • Thanks Eric.

    I'll try and rally the troops as well as the influencers and see what kind of "pressure" we can put on the city to get their provider to re-establish a service that exposes the data using Atom format.

    Did I mention they are at https://data.edmonton.ca/? Just to be clear, it is https://data.edmonton.ca/. (hint hint)

    Cheers. 


    PP

    Tuesday, March 20, 2012 9:59 PM
  • Thanks Eric.

    I'll try and rally the troops as well as the influencers and see what kind of "pressure" we can put on the city to get their provider to re-establish a service that exposes the data using Atom format.

    Did I mention they are at https://data.edmonton.ca/? Just to be clear, it is https://data.edmonton.ca/. (hint hint)

    Cheers. 


    PP

    I notice that they do support xml  ( http://data.edmonton.ca/api/views/5zeu-wkpv/rows.xml ) but it's still SODA and not OData, unfortunately...  Would be nice if Socrata supported OData - a lot of public data sources are using them.

    Tuesday, March 20, 2012 10:05 PM
  • Eric,

    Thank you for your post.

    But I am unable to implement the solution in kendo UI using Light Switch OData.

    How to include the above line in my http request as they are acepting only URL.

    I am looking for a jason format from Light Switch OData.

    Any example would be great.

    Regards

    Rama


    Rama dwarapudi

    Wednesday, May 2, 2012 10:15 PM
  • Eric,

    Thank you for your post.

    But I am unable to implement the solution in kendo UI using Light Switch OData.

    How to include the above line in my http request as they are acepting only URL.

    I am looking for a jason format from Light Switch OData.

    Any example would be great.

    Regards

    Rama


    Rama dwarapudi

    This example uses DataJs and calls Lightswitch and gets JSON back:

    A Full CRUD DataJs and KnockoutJs LightSwitch Example Using Only An .Html Page

    image


    The Visual Studio LightSwitch Marketplace

    http://LightSwitchHelpWebsite.com

    Wednesday, May 2, 2012 11:01 PM