[wp-trac] [WordPress Trac] #33055: Support Parallel HTTP Requests in WP_Http, et al

[WordPress Trac]

#33055: Support Parallel HTTP Requests in WP_Http, et al
----------------------------------------+--------------------------
 Reporter:  wonderboymusic              |       Owner:  rmccue
     Type:  task (blessed)              |      Status:  assigned
 Priority:  high                        |   Milestone:  4.6
Component:  HTTP API                    |     Version:
 Severity:  normal                      |  Resolution:
 Keywords:  needs-patch needs-dev-note  |     Focuses:  performance
----------------------------------------+--------------------------

Comment (by giuseppe.mazzapica):

 HTTP API is a public API, and since the API exists all public API methods
 are documented to return an array, so I think is not a good idea just
 switch the return type.

 If I am not wrong, WordPress core itself used to check `is_array` for HTTP
 API response. It's not that hard to imaginate a lot of code out there is
 doing the same.

 Moreover, changing return type also means that any code using type-hint is
 going to break.

 For example:

 {{{#!php
 function do_something_with_response(array $response) {
   /* ... */
 }


 $response = wp_remote_get( /* ... */ );

 if ( is_wp_error( $response ) ) {
   // do something with error
 }

 do_something_with_response( $response );
 }}}

 The code above uses `is_error` what seems to be the ''correct'' way to
 check for proper response, but still fails, because the changed return
 type.

 Even if there are functions like `wp_remote_retrieve_body()` or
 `wp_remote_retrieve_headers()` and similar, they are considered just
 "helpers" in official documentation (see Codex:
 https://codex.wordpress.org/HTTP_API#Helper_Functions).

 English is not my native tongue, but I think that "helpers" != "mandatory"
 and more so "helpers" != "recommended", or am I wrong?

 Developers, because reasons, expect WordPress to be backward compatible
 even in its internal API, surely they expect to be strongly backward
 compatible in public API.

 At least, I do. And I found myself pretty "safe" using a return type of a
 public API method for my type-hint.

 Changing return type of an entire API methods is a **huge** backward
 compatibility break.

 I, for myself, am pretty sure 90% of the my code that uses HTTP API is
 going to break because of this change.

 My point is: why don't convert to array the object returned by Requests
 and so be 100% backward compatible?

 In that case would also be possible to add an argument, e.g. something
 like `response_type` and defaults to array and let users decide if they
 want an object.

 In the other cases, convert `Request_Response` to array is very easy,
 something like:

 {{{#!php
 $response = Requests::request( /* ... */ );

 if ( isset( $args['response_type'] ) && OBJECT == $args['response_type'] )
 ) {
   return $response;
 }

 $response_array = get_object_vars( $response );

 // headers is an instance of Requests_Response_Headers
 $response_array['headers'] = iterator_to_array(
 $response_array['headers']->getIterator() );

 // cookies is an instance of Requests_Cookie_Jar
 $response_array['cookies'] = iterator_to_array(
 $response_array['cookies']->getIterator() )

 return $response_array;
 }}}

 WordPress did much worse things for backward compatibility.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/33055#comment:54>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform