[wp-trac] [WordPress Trac] #14618: Proposal: Standardize WP Responses to JS Requests as JSON

[WordPress Trac]

#14618: Proposal: Standardize WP Responses to JS Requests as JSON
-------------------------+--------------------------------------------------
 Reporter:  filosofo     |       Owner:                
     Type:  enhancement  |      Status:  new           
 Priority:  normal       |   Milestone:  Future Release
Component:  JavaScript   |     Version:  3.0           
 Severity:  normal       |    Keywords:  needs-patch   
-------------------------+--------------------------------------------------

Comment(by filosofo):

 Replying to [comment:13 josephscott]:
 > I followed the JSON-RPC development for awhile, one thing they never
 addressed very well (to my knowledge) was binary data.  This is also the
 single biggest weakness in XML-RPC from my point of view.  For *RPC style
 APIs binary data ends up being base64 encoded, which is an added burden
 that isn't really needed.  Being able to do a direct HTTP POST with raw
 binary data is both easier and more efficient.

 What is the current use case in which you're posting binary data via XHR?

 > Another, often less observed, weakness is no specific way to version the
 API.  Contrast this with an HTTP based API, which can include version
 numbers as part of the URL string (just as an example: /json-api.php/wp-
 delete-comment/1.0/).

 You could easily add an argument to the endpoint to indicate version:
 {{{
 admin-ajax.php?json-api=1.0
 }}}
 or pass it as one of the JSON parameters (`{json-api-version: "1.0"}`).


 > I've yet to find a compelling reason to use an RPC style API instead of
 a general HTTP one.  I'm happy to be convinced other wise.

 I listed some in the OP. I've been using my JSON RPC plugin on a number of
 sites now, and the biggest benefits are:
  * Standardization: I don't have to worry about any other Ajax
 functionality or libraries: I just check for the JS methods and call them
 if available.
  * Consistent Response Handling: Responses can be only one of the
 following:
    * Syntactically invalid response (this includes blank responses)
    * Successful response
    * Error response
 All are easy to check for in the JSON RPC API, making it easy to handle
 problems.  In contrast, the current core Ajax responses can take any of a
 number of forms, including no response for a successful request.  This
 makes it difficult to test and to use by plugins.  It also requires that
 each piece of code making a request include the logic necessary to
 determine success or failure, which is needless redundancy.

 > As for the general idea, this strikes me as something that would do well
 as a core plugin, something that ships with WP and is even enabled by
 default, but is developed and updated as a plugin.  This allows for
 advancements and bug fixes that aren't limited by the overall WP release
 schedule.

 Perhaps.  Ultimately it's not much use if plugin and theme developers
 can't use it.

 I'll post a link to my plugin below, although I still want to verify that
 it works with 3.1 and make a sample use plugin, before doing a real
 release.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/14618#comment:14>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software