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

Comments

Projects
None yet
4 participants
@HipsterJazzbo
Contributor

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

This comment has been minimized.

Show comment
Hide comment
@jasonlewis

jasonlewis Nov 14, 2014

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@HipsterJazzbo

HipsterJazzbo Nov 14, 2014

Contributor

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)

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@jasonlewis

jasonlewis Nov 16, 2014

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@HipsterJazzbo

HipsterJazzbo Nov 16, 2014

Contributor

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)

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@jasonlewis

jasonlewis Nov 16, 2014

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@HipsterJazzbo

HipsterJazzbo Nov 16, 2014

Contributor

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)

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@jasonlewis

jasonlewis Nov 16, 2014

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@HipsterJazzbo

HipsterJazzbo Nov 16, 2014

Contributor

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)

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@kirkbushell

kirkbushell Nov 27, 2014

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@jasonlewis

jasonlewis Nov 27, 2014

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@HipsterJazzbo

HipsterJazzbo Nov 27, 2014

Contributor

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).

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@Tom5om

Tom5om 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 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

This comment has been minimized.

Show comment
Hide comment
@Tom5om

Tom5om 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!

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

This comment has been minimized.

Show comment
Hide comment
@jasonlewis

jasonlewis Aug 5, 2015

Contributor

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.

Contributor

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