Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider putting pagination data in headers? #246

Closed
hipsterjazzbo opened this issue Nov 14, 2014 · 14 comments
Closed

Consider putting pagination data in headers? #246

hipsterjazzbo opened this issue Nov 14, 2014 · 14 comments
Labels

Comments

@hipsterjazzbo
Copy link
Contributor

@hipsterjazzbo hipsterjazzbo commented Nov 14, 2014

I've been wondering lately if it might be worth putting pagination data in headers. There are a lot of times when I just want to know how many of something there are, and it'd be sweet if I could do a HEAD request to find out.

This article has some interesting thoughts on using Range headers for this purpose.

Thoughts?

@jasonlewis
Copy link
Contributor

@jasonlewis jasonlewis commented Nov 14, 2014

Yeah it's definitely on my list of things to look at. The current oldest open issue (#41) is about this very thing, I believe. I don't think it'd be too hard. Just need to think of a good way of doing it from the data that a user returns in their controller.

Perhaps it could be a part of the response builder.

@hipsterjazzbo
Copy link
Contributor Author

@hipsterjazzbo hipsterjazzbo commented Nov 14, 2014

I imagined it'd be done from the same place that pagination data is already inserted when returning pagination models.

On Fri, Nov 14, 2014 at 5:17 PM, Jason Lewis notifications@github.com
wrote:

Yeah it's definitely on my list of things to look at. The current oldest open issue (#41) is about this very thing, I believe. I don't think it'd be too hard. Just need to think of a good way of doing it from the data that a user returns in their controller.

Perhaps it could be a part of the response builder.

Reply to this email directly or view it on GitHub:
#246 (comment)

@jasonlewis
Copy link
Contributor

@jasonlewis jasonlewis commented Nov 16, 2014

Okay so reading through that article it seems a bit different to what was originally requested in #41. The Range header seems a lot more complex as it would require the API to read incoming headers (the Content-Range header) and make the value available to routes that are paginating data.

I think it's possible. But I'm not sure what route would be the best to take. The Link header seems to be less liked among the RESTful enthusiasts for whatever reason. They do seem to achieve different things though.

@hipsterjazzbo
Copy link
Contributor Author

@hipsterjazzbo hipsterjazzbo commented Nov 16, 2014

I think the deal with the link header is that it doesn’t really serve other uses for pagination data, particularly the total number of results and the quantity per page.

Total number of results especially can be useful for things other that just going between pages.

On Sun, Nov 16, 2014 at 3:59 PM, Jason Lewis notifications@github.com
wrote:

Okay so reading through that article it seems a bit different to what was originally requested in #41. The Range header seems a lot more complex as it would require the API to read incoming headers (the Content-Range header) and make the value available to routes that are paginating data.

I think it's possible. But I'm not sure what route would be the best to take. The Link header seems to be less liked among the RESTful enthusiasts for whatever reason. They do seem to achieve different things though.

Reply to this email directly or view it on GitHub:
#246 (comment)

@jasonlewis
Copy link
Contributor

@jasonlewis jasonlewis commented Nov 16, 2014

No, the Link header is primarily used for navigating through results by simply grabbing the "next" link from the header and requesting it. Makes it easier to traverse. However I have read that it's not the best way to go about it.

The Range header on the other hand (in my opinion) seems to solve the problem of putting page numbers and what not in the query string, which keeps the URI nice and clean. Which I like.

@hipsterjazzbo
Copy link
Contributor Author

@hipsterjazzbo hipsterjazzbo commented Nov 16, 2014

I have to admit, I’m primarily after this functionality to mis-use it. I just want to get total result count from a HEAD request :P

On Sun, Nov 16, 2014 at 4:55 PM, Jason Lewis notifications@github.com
wrote:

No, the Link header is primarily used for navigating through results by simply grabbing the "next" link from the header and requesting it. Makes it easier to traverse. However I have read that it's not the best way to go about it.

The Range header on the other hand (in my opinion) seems to solve the problem of putting page numbers and what not in the query string, which keeps the URI nice and clean. Which I like.

Reply to this email directly or view it on GitHub:
#246 (comment)

@jasonlewis
Copy link
Contributor

@jasonlewis jasonlewis commented Nov 16, 2014

Heh, well I'll look into it for sure. You could implement the route yourself though, right? Just return a custom header or whatever.

@jasonlewis jasonlewis closed this Nov 16, 2014
@jasonlewis jasonlewis reopened this Nov 16, 2014
@hipsterjazzbo
Copy link
Contributor Author

@hipsterjazzbo hipsterjazzbo commented Nov 16, 2014

Yeah totally, just thought I'd bring it up as a generally useful thing.

On Sun, Nov 16, 2014 at 5:10 PM, Jason Lewis notifications@github.com
wrote:

Reopened #246.

Reply to this email directly or view it on GitHub:
#246 (comment)

@kirkbushell
Copy link
Contributor

@kirkbushell kirkbushell commented Nov 27, 2014

This is really fascinating. At first I was skeptical, but after thinking about it - it actually makes perfect sense.

@jasonlewis
Copy link
Contributor

@jasonlewis jasonlewis commented Nov 27, 2014

Yeah I do kind of like this Range header. I'm still torn on the direction I should take with both this and the Link header though. Probably something I'll investigate more for 0.8.

@hipsterjazzbo
Copy link
Contributor Author

@hipsterjazzbo hipsterjazzbo commented Nov 27, 2014

I think they serve different purposes. One is designed to explicitly give the next/prev links necessary to implement pagination, while the other is for provided raw metadata for any number of purposes.

On 27/11/2014, at 2:25 pm, Jason Lewis notifications@github.com wrote:

Yeah I do kind of like this Range header. I'm still torn on the direction I should take with both this and the Link header though. Probably something I'll investigate more for 0.8.


Reply to this email directly or view it on GitHub #246 (comment).

@Tom5om
Copy link

@Tom5om Tom5om commented Mar 1, 2015

I am really interested in this feature, I am going to look into extending the package to do that as I really need it. If you guys have any tips on how to do it that would be greatly appreciated!

@Tom5om
Copy link

@Tom5om Tom5om commented Mar 2, 2015

To do this as a quick and dirty solution i have added this in the morph function of the Response.php file:

     } elseif (is_array($content) || $content instanceof ArrayObject || $content instanceof ArrayableInterface) {

        //check if meta key exists for pagination data
        if(array_key_exists('meta', $content)) {

            //get the meta data
            $meta = $content['meta'];

            //set a header for each pagination item in the meta data
            foreach ($meta['pagination'] as $key => $val) {
                $this->headers->set(camel_case('pagination_'.$key), $val);
            }

            //remove the meta data from the array
            unset($content['meta']);
        }

        $content = $formatter->formatArray($content);
    }

Obviously this is a quick and very dirty solution, but I am not very familiar with dingo yet, if any of you could point me in the right direction how this could be done more clean that would be much appreciated!

@jasonlewis
Copy link
Contributor

@jasonlewis jasonlewis commented Aug 5, 2015

I've decided against adding this to the core. I have just implemented some events that you can use to tweak the response before and after morphing.

Refer to docs for more: https://github.com/dingo/api/wiki/Responses#morphing-and-morphed-events

Going to close this now.

@jasonlewis jasonlewis closed this Aug 5, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.