Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Paginate api for finding submitted requisitions and fix 404

Description

The /requisitions/submitted resource should be updated such that:

  • It supports pagination. (Note that this is a breaking UI change because even though the request to the endpoint needn't change, the response body does.)

  • It never returns a 404. Rather, like all of our collections, it returns an empty array if no elements exists.

Acceptance:

  • /api/requisitions/submitted is pageable, like /api/requisitions/search

  • /api/requisitions/submitted never returns a 404. It should return an empty list (a Page with no contents).

  • UI team is notified that this is a breaking change, and they will schedule work from it. and (: UI doesn't use this endpoint)

  • RAML needs to reflect it's Pageable (trait query parameters and return type)

  • RAML needs to reflect that 404's never returned

  • any applicable tests updated

Confluence content

mentioned on

QAlity Plus - Test Management

Checklists

Activity

Show:
Lucyna Laska
February 10, 2017 at 1:34 PM

All good.

Endpoint: GET /api/requisitions/submitted is pageable. 404 is not returned anymore.

Ben Leibert
January 26, 2017 at 6:53 AM
(edited)

Hi . I noticed that this endpoint erroneously returns a 404 in cases wherein it should return an empty collection (and associated 200 status code). We should probably fix this prior to 3.0 because it’s a breaking API change, and we should strive to make such changes as seldom as possible post-release.

Adding pagination to the endpoint isn’t important per se, but it’s also a breaking API change. I thus added it to this ticket’s in order to minimize the number of times this endpoint is subject to non-backward compatible updates. A holistic title like “make this endpoint great again” would have captured the spirit of the ticket. : )

I’m under the impression (but haven’t verified) that other endpoints also erroneously return 404 status codes – just like this one. It wouldn’t be unreasonable to:

A) Write an alternate ticket that involves finding and fixing all such endpoints.
B) Perhaps worrying about paging later.

If we’re going to limit ourselves to just this endpoint, though, I’d suggest we throw in paging too. Thanks to our superbly great pattern (just kidding), it’s not much extra work.

Brandon Bowersox-Johnson
January 26, 2017 at 6:07 AM

Can you explain a bit about why we've got to get this done before 3.0 (or who said it was a must-have)? It's great that we can add pagination to anything now that we have a pattern. But why this endpoint?

Done
Pinned fields
Click on the next to a field label to start pinning.

Details

Assignee

Reporter

Story Points

Original estimate

Time tracking

1d 5h logged1d 3h remaining

Components

Sprint

None

Fix versions

Priority

Time Assistant

Created January 22, 2017 at 8:49 PM
Updated February 10, 2017 at 7:05 PM
Resolved February 10, 2017 at 1:35 PM