[wp-trac] [WordPress Trac] #51909: REST API inconsistencies

[WordPress Trac]

#51909: REST API inconsistencies
--------------------------+------------------------------
 Reporter:  icameron      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  REST API      |     Version:  4.8
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------
Changes (by SergeyBiryukov):

 * version:   => 4.8


Old description:

> Changeset 39967 introduced a new behavior in parts of the API.  A request
> for posts with a page parameter that is out of range results in a status
> 400 and rest_post_invalid_page_number error response.
>
> This is different behavior than the class-wp-rest-users-controller, which
> happily returns a status 200 with an empty array, and it always has.
> Status 200 with an empty array is the more correct behavior, in my
> opinion.
>
> A status 400 would be for bad requests, not for valid requests that
> result in empty results.  Would you return a status 400 for a search
> filter with no results?  That's conceptually similar to an out-of-range
> page in the parameters.  Regardless, the most important for developer
> experience, I think, is stability and consistency.  Unfortunately this
> change introduced instability (when people upgrade from old versions) and
> inconsistency (when new developers write clients for the rest api and get
> different behavior from posts than from users).

New description:

 Changeset [39967] introduced a new behavior in parts of the API.  A
 request for posts with a page parameter that is out of range results in a
 status 400 and rest_post_invalid_page_number error response.

 This is different behavior than the class-wp-rest-users-controller, which
 happily returns a status 200 with an empty array, and it always has.
 Status 200 with an empty array is the more correct behavior, in my
 opinion.

 A status 400 would be for bad requests, not for valid requests that result
 in empty results.  Would you return a status 400 for a search filter with
 no results?  That's conceptually similar to an out-of-range page in the
 parameters.  Regardless, the most important for developer experience, I
 think, is stability and consistency.  Unfortunately this change introduced
 instability (when people upgrade from old versions) and inconsistency
 (when new developers write clients for the rest api and get different
 behavior from posts than from users).

--

Comment:

 Hi there, welcome to WordPress Trac! Thanks for the report.

 [39967] went into WordPress 4.8, setting the Version field accordingly to
 reflect that as the earliest applicable version.

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