I have developed a Web Interface for a db. The db and Web Interface are for my own use in my hobby running on my private intranet. Currently the db has 1800+ records which is going to increase with usage. Ver 1 of the Web Interface listed all records (~2.5KB) on a single page requiring a ton of scrolling. Vers 2 of the Web interface introduced pagination where records are grouped into a non-fixed size of roughly 100 records. On page load all 1800+ records are still transferred to the client but only the first page is "visible", the other 17 are hidden. I use a series of "non-submit" buttons with JS on-click functionality to hid the current page and make the selected page visible. Better in that scrolling is limited to ~100 records. Vers 3 only transfers the first page and the paging buttons on page load. Now, the on-click function using fetch() API sends a GET Request with parameters to fetch the desired page then swaps it into the DOM. The parameters specify a starting and ending points for the page. These values come from the paging buttons supplied by the server on page load. Works well with significantly reduced data transfer size. In Vers 4 I am generalize the fetch() API GET Request parameters to send user specified parameters to allow the user to choose any page starting and ending point. (Note: The user can not specify a page size directly.) So if the user selects a start and end point that no records fall into my plan is to use HTTP Response Code 204 "No Content" to tell the JS code that there are no matching records and nothing to swap. Is this the appropriate Response Code? Should I be including any other Header information in the Response with the 204 code?
Asked
Active
Viewed 236 times
1 Answers
0
Take a look at what the RFC says about 204:
https://www.rfc-editor.org/rfc/rfc7231#section-6.3.5
It's really intended for PUT requests. I think for what you are doing, it's fine to return 200 and no body, with a Content-Length header of 0.
