Loading ...
Sorry, an error occurred while loading the content.

Guidance on standard JSON output.

Expand Messages
  • Venkat M
    Hi,   I have a general question on JON outputs and usage. I was a flex developer for quite a bit of time and now I am planning to move my application to
    Message 1 of 2 , Mar 14, 2012
    • 0 Attachment
      Hi,
       
      I have a general question on JON outputs and usage. I was a
      flex developer for quite a bit of time and now I am planning to move my
      application to JS+HTML.
      All the call that were RPC in flex mode was made to support
      REST now. The output is a jSON and I make AJAX calls and with the help of
      JQuery I am able to work on. It is good and working fine.
       
      Now I have a standardization question.
      I currently have about 15 calls (it
      may increase). Is it advised to have a same JSON o/p pattern for all the calls?
      Or is it okay even if independent calls have different formats.
      Ex:
      Login:  [ I just need the single value Key in the
      output]
      errorCode: null
      errorMessage: null
      key: "ABCD_1234"
      result: "OK"
      rootCause: null
      status: "OK"
       
      List:  [ I need all the “entryId’s from result to be into a
      select box may be]
      errorCode: null
      errorMessage: null
      key: null
      result: "[{"entryId":"test","entryValue":"Testing"},{"entryId":"Run","entryValue":"Running"},{"entryId":"work","entryValue":"working"},{"entryId":"marktest","entryValue":"Mark's
      play pen"},{"entryId":"kill","entryValue":"Killing"}]"
      rootCause: null
      status: "OK"
       
      Now, I am parsing the result field
      of JSON (using parseJSON) and then working on it. However the other fields of
      the parent JSON are useless in the LIST call (like key, error etc). I still had
      the same template of JSON that I used for login to have it same for all the
      routines. This makes me inform anyone that the point to catch is in RESPONSE of
      JSON. Is this okay? Or do you suggest to have separate JSON pattern for each
      call? and avoid parsing pattern and use the native JSON output.
      Since I am currently in the development
      stage, I would not hesitate to make a change to make it work industry standard.
      Thanks!

      Response and guidance is greatly appreciated.
       
        
      Cheers,
      Venkat.

      [Non-text portions of this message have been removed]
    • Stephan Beal
      ... i have a bit of experience in this area, e.g.: https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/view
      Message 2 of 2 , Mar 14, 2012
      • 0 Attachment
        On Wed, Mar 14, 2012 at 5:59 PM, Venkat M <venkat_yum@...> wrote:

        > **
        >
        > Now I have a standardization question.
        > I currently have about 15 calls (it
        > may increase). Is it advised to have a same JSON o/p pattern for all the
        > calls?
        >

        i have a bit of experience in this area, e.g.:

        https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/view
        http://whiki.wanderinghorse.net/

        and personally recommend using an evelope+body model, for both the requests
        and response. i've tried the approach you're using (from what i
        understand), and IMO it's not as scalable. It works fine for small APIs,
        but i have come to prefer the extra level of an envelope for
        framework/global-level properties and a payload/body for the app-level data
        because it ensures that both the clients and the framework won't step on
        each other's data (i.e. they have separate namespaces). The above document
        demonstrates what i currently use in my various JSON back-ends. Rather than
        roll your own, you might want to pick some library which already handles
        such communication, leaving the client to only deal with creating the
        requests and handling the responses. If you're interested, write me
        off-list and i can give you a JS class i've been evolving the past several
        years (and actively use on at least 5 projects) which provides a generic
        client-side API for handling arbitrary JSON-based back-ends.

        --
        ----- stephan beal
        http://wanderinghorse.net/home/stephan/
        http://gplus.to/sgbeal


        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.