none
JSON as alternative to XML for REST requests?

    Question

  • Hi, am I missing something? Is there (or when planned) a way to use JSON to format the request payloads instead of XML? We use Json for all of our REST activities in our current (pure Microsoft-based) applications. Ideas. Tips?

    Thanks,
    Richard
    Hubert-Associates
    Thursday, November 20, 2008 7:37 AM

Answers

  • Richard:

    I am actually able to get both JSON and Atom returns from my SDS data stores using a slightly different URL:
    https://<authority>.data.database.windows.net/adods/v1/<container>/Entities('<entity-id>')

    I can set the "accept" header to eithet "application/json" or "application/atom+xml" to affect the response.

    An example of the response/request below:
    REQUEST: **************
    GET /adods/v1/customers/Entities('c1') HTTP/1.1
    accept:application/json
    Host: mcav2.data.database.windows.net
    Authorization: Basic XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    RESPONSE: **************
    HTTP/1.1 200 OK
    Cache-Control: no-cache
    Transfer-Encoding: chunked
    Content-Type: application/json;charset=utf-8
    ETag: W/"51356L"
    x-msft-request-id: 967ae36d-93bd-4052-a919-6e5e1e64df16
    DataServiceVersion: 1.0;
    Date: Thu, 20 Nov 2008 16:03:44 GMT

    { "d" : {
    "__metadata": {
    "uri": "http://mcav2.data.database.windows.net/adods/v1/customers/Entities(\'c1\')", "etag": "W/\"51356L\"", "type": "SSDS.Entity"
    }, "Id": "c1", "Kind": "Customer", "Version": "51356", "Name": "Customer 1", "AddressLine1": "111 Maple", "City": "Seattle"
    } }

    Couple things:
    - I'm told this is 'experimental' right now, so it might go away, might change, etc.
    - I notice that this uses a completely different query syntax (Astoria?). Not really into that (I like the LINQ-type query syntax).
    - Not a fan of having to use a diff URL than the Entity-XML requests, but again, it's experimental
    - Not sure about the serialization of the metadata here. "__metadata"? Why the "W/" on the ETag? is it really a weak etag? Entity-XML doesn't send "weak" etags.

    Anyway, at least you can check this out and see a possibility of the future, eh?

     

    Mike Amundsen [http://amundsen.com/blog/]
    Thursday, November 20, 2008 4:11 PM
  • Evan:

    Please accept the following items as suggestions as you 'bake' in JSON/Atom support for SDS:

    - use the *exact same URL* for each serialization format when using the REST interface. use the "Accept" header to control the return type:
    GET /v1/customers/cust-001 HTTP/1.1
    accept:application/json
    Host: mcav2.data.database.windows.net


    GET /v1/customers/cust-001 HTTP/1.1
    accept:application/atom+xml
    Host: mcav2.data.database.windows.net


    GET /v1/customers/cust-001 HTTP/1.1
    accept:application/x-ssds+xml
    Host: mcav2.data.database.windows.net


    NOTE: if you don't want to rely strictly on Accept headers for conneg, use "file-tails" as an _additional_ option (cust-001.json, cust-001.atom, cust-001.xml)
    - make sure the header collection is the same for each response type, too. Right now Astoria returns  ETags marked "weak"; the "DataServiceVersion" header, etc.
    - make sure the same query language can be used for all MIME-types. (FWIW, I prefer the LINQ-style syntax).


    BTW, it would really be nice if you could make sure schema references can be de-referenced. currently x-ssds+xml MIME type refers to several schemas that can't be returned. the atom+xml one does, too.

    As usual, thanks for the chance to provide feedback.


    Mike Amundsen [http://amundsen.com/blog/]
    Thursday, November 20, 2008 10:48 PM

All replies

  • The ability to use JSON is coming in the future - http://sqlserviceslabs.net/SDSAstoria.html.

    Evan
    Thursday, November 20, 2008 2:40 PM
  • Richard:

    I am actually able to get both JSON and Atom returns from my SDS data stores using a slightly different URL:
    https://<authority>.data.database.windows.net/adods/v1/<container>/Entities('<entity-id>')

    I can set the "accept" header to eithet "application/json" or "application/atom+xml" to affect the response.

    An example of the response/request below:
    REQUEST: **************
    GET /adods/v1/customers/Entities('c1') HTTP/1.1
    accept:application/json
    Host: mcav2.data.database.windows.net
    Authorization: Basic XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    RESPONSE: **************
    HTTP/1.1 200 OK
    Cache-Control: no-cache
    Transfer-Encoding: chunked
    Content-Type: application/json;charset=utf-8
    ETag: W/"51356L"
    x-msft-request-id: 967ae36d-93bd-4052-a919-6e5e1e64df16
    DataServiceVersion: 1.0;
    Date: Thu, 20 Nov 2008 16:03:44 GMT

    { "d" : {
    "__metadata": {
    "uri": "http://mcav2.data.database.windows.net/adods/v1/customers/Entities(\'c1\')", "etag": "W/\"51356L\"", "type": "SSDS.Entity"
    }, "Id": "c1", "Kind": "Customer", "Version": "51356", "Name": "Customer 1", "AddressLine1": "111 Maple", "City": "Seattle"
    } }

    Couple things:
    - I'm told this is 'experimental' right now, so it might go away, might change, etc.
    - I notice that this uses a completely different query syntax (Astoria?). Not really into that (I like the LINQ-type query syntax).
    - Not a fan of having to use a diff URL than the Entity-XML requests, but again, it's experimental
    - Not sure about the serialization of the metadata here. "__metadata"? Why the "W/" on the ETag? is it really a weak etag? Entity-XML doesn't send "weak" etags.

    Anyway, at least you can check this out and see a possibility of the future, eh?

     

    Mike Amundsen [http://amundsen.com/blog/]
    Thursday, November 20, 2008 4:11 PM
  • What Mike is doing is actually the Astoria functionality.  It does work, but is not an entirely "baked" part of the product.

    Evan
    Thursday, November 20, 2008 10:28 PM
  • Evan:

    Please accept the following items as suggestions as you 'bake' in JSON/Atom support for SDS:

    - use the *exact same URL* for each serialization format when using the REST interface. use the "Accept" header to control the return type:
    GET /v1/customers/cust-001 HTTP/1.1
    accept:application/json
    Host: mcav2.data.database.windows.net


    GET /v1/customers/cust-001 HTTP/1.1
    accept:application/atom+xml
    Host: mcav2.data.database.windows.net


    GET /v1/customers/cust-001 HTTP/1.1
    accept:application/x-ssds+xml
    Host: mcav2.data.database.windows.net


    NOTE: if you don't want to rely strictly on Accept headers for conneg, use "file-tails" as an _additional_ option (cust-001.json, cust-001.atom, cust-001.xml)
    - make sure the header collection is the same for each response type, too. Right now Astoria returns  ETags marked "weak"; the "DataServiceVersion" header, etc.
    - make sure the same query language can be used for all MIME-types. (FWIW, I prefer the LINQ-style syntax).


    BTW, it would really be nice if you could make sure schema references can be de-referenced. currently x-ssds+xml MIME type refers to several schemas that can't be returned. the atom+xml one does, too.

    As usual, thanks for the chance to provide feedback.


    Mike Amundsen [http://amundsen.com/blog/]
    Thursday, November 20, 2008 10:48 PM
  • Evan,

    As you progress from half-baked to well-done, please keep POX in the picture.

    I fought the good battle with Pablo for POX in Astoria, but lost. I'd not like to see that happen again.

    Cheers,

    --rj


    OakLeaf Blog

    • Edited by Roger Jennings Friday, November 21, 2008 7:14 PM remove lf
    Friday, November 21, 2008 7:13 PM
  • Evan (nice how you get all the feedback, eh?):

    I agree w/ Roger. Since we currently have POX via the REST head today, I expect that to continue w/o significant changes. Adding other serialization formats (JSON, Atom, CSV, PDF, SVG, [shall I continue?]) shoud not, IMO, alter the standing of any of the existing serialization formats.

    I'm not really interested in what library name to which this stuff is referred (Astoria, etc.) as long as the MIME-types and serializations are high-fidelity and easy to access via common URIs.




    Mike Amundsen [http://amundsen.com/blog/]
    Friday, November 21, 2008 8:25 PM
  • It would seem with a server extention (i.e. reply interceptor), one could create server-side methods to return any format (or future format) they wanted.  Baring that, if you have xml or json, you should be able to convert to any other format fairly easy on the client.   I want to live in a world where I don't see or care about the wire format.  We can all dream.
    Saturday, November 22, 2008 3:43 AM
  • WS:

    yep - that's the way i see it, too.

    The server should be prepared to return any one of a set of available formats. HTTP supports clients sending an OPTIONS request to see the possible Accept types that can be returned for any given request. Then the client can use one of those accept types (application/json) etc. when making the request to the server. The server can pull the data form SDS, then run the results through a transform to produce the desired output. for me, allowing clients to make that decision along the way is a key feature of a solid SDS interface.

    All pretty standard stuff. Currently, there is nothing 'out of the box' from the .NET libraries with this kind of support, but it can be built w/o too much hassle. The challenge I see is that the Astoria project took one approach to this and WCF took another. And the SDS team is using a variation of this (if i understand it correclty) w/ their REST interface.

    Hopefully, the MIME-type support 'story' for SDS will all start to come together in the near future.




    Mike Amundsen [http://amundsen.com/blog/]
    Saturday, November 22, 2008 4:16 AM
  • UPDATE: Azure SQL Database now supports JSON: https://blogs.msdn.microsoft.com/sqlserverstorageengine/2016/04/09/json-is-available-in-azure-sql-database/
    Saturday, April 9, 2016 1:31 PM