xmlrpc "getrecentposts" inconsistent with "getpost"

[kevbo]

In /wp-includes/class-wp-xmlrpc-server.php the return array for mw_getPost sets the postid as an int. For mw_getRecentPosts postid is cast as a string. (lines 1827 & 2810)

Rev [16508] first cast the int as string in response to ticket #15517. The reference given was an old MSDN article. However, the Blogger API actually says the post ID should be numerical, not a string.

(See Blogger API Post definition here: ​https://developers.google.com/blogger/docs/2.0/json/reference/posts#resource)

Suggestion: Remove the cast to string for postid.

(Clients which use XML-RPC calls likely (and logically) expect that the struct of the post should be the same. For example, the .NET library JoeBlogs expects that mw_getPost return a certain struct whereas mw_getRecentPosts would return an array of structs.)

Remove postid casts to string

The linked Blogger API (JSON v2) is not the same API as the one that WordPress implements (XML-RPC v1, whose spec no longer seems to exist anywhere that I can find online). The metaWeblog ​API spec says that the ID should be a string.

In any case, I think it would definitely be inadvisable to change the type yet again and break clients that have been working since 3.1.

Thanks for the API catch.

I can only ever find the post ID referred to as an integer, even in the metaWeblog API spec. See the link "response" here: ​http://xmlrpc.scripting.com/metaWeblogApi.html#requestAndResponse

<member>
	<name>postid</name>
	<value>
		<i4>1829</i4>
	</value>
</member>

In any case, I believe that both getPost and getRecentPosts should return the same array sub-types, don't you? Actually, the blogger implementation (blogger_getPost and blogger_getRecentPosts) returns a post ID as string for both functions. However, the metaWeblog doesn't (mw_getPost is int, mw_getRecentPosts is string.)

My client broke when I updated from a pre 3.1 WordPress install to the most recent one. Smart client developers will hopefully catch and cast the XML-RPC response; mine didn't. I think that some clients may break, but that shouldn't prevent us from being consistent in the code.

(BTW, I'm now unsure if it's actually since 3.1. I'll investigate.)

First of all that are two different API's and the implementation is different. Also clients should try to use the wp.* methods.

That said we really can’t change it because things will break. At least from my experience with iOS development.