From what is described this PR does exactly what it says. I dont know enough to determine if it is correct to remove the unnecessary pagination links but it does what it says

I dont know enough to determine if it is correct to remove the unnecessary pagination links but it does what it says

JSON API as a spec doesn't have strong opinions https://jsonapi.org/format/#fetching-pagination it just says "Keys MUST either be omitted or have a null value to indicate that a particular link is unavailable.". My feeling is first/last as a link is available so should be present (even if it's the current page). But I would definitely agree that having previous/next as nullable makes sense. As with all these subjective things - it's always down to personal preference :)

My feeling is first/last as a link is available so should be present (even if it's the current page)

In the gui they would be disabled

Hi, I'd like to better understand your responses:
is the workaround proposed by @stefanoel consistent or not ?
Is it worthwhile for Joomla4 ?

The changes to next/previous page is a good change. I think the first/last links should always be present.
I also think the view shouldn't be setting state into the model - it should be handled in the controller already.

The question of whether to include first/last/next/previous links on pages where they are redundant is one I've thought about before. As a rule of thumb I prefer to avoid them. My reasoning is that links are pointers to possible state transitions (that's what HATEOAS is all about), but redundant links are a bit like empty promises; it looks like they should lead to a state transition but actually they just lead straight back to the current state.

The client needs to know definitively that it has reached the first/last page when paginating. Including redundant links means that the client must compare the current URI with the first/last link URI and decide if they're the same or not. This can sometimes be tricky if the request URI can include arguments that don't affect the result set: how does the client know to ignore them when URI structure is supposed to be opaque? A simple string comparison may not suffice; it must reduce both to a canonical form before the comparison. It's only really safe to include redundant links if there are other signals that the client can use to decide whether it needs to follow a link or not. For example, if there are separate pageNumber and pageCount attributes returned in the response.

So, in my opinion, if you include redundant links, you should also include pageNumber and pageCount (or something similar) and encourage developers not to do URI comparisons. On the other hand, omitting redundant links doesn't mean that you should omit pageNumber/pageCount as they can be used by clients that want to randomly access pages.

So my preference is to omit redundant links but include pageNumber/pageCount (or better still something like Offset and totalCount as the concept of a page can be a bit problematic). And on a first pass at least, assume that the data is essentially static so you don't have to worry about insertions and deletions accidentally resulting in duplications and omissions when paginating; that's a whole other problem to solve.

There already is a total-pages property available.

The client needs to know definitively that it has reached the first/last page when paginating

That's why you use the next/previous attributes for in JSON API

This can sometimes be tricky if the request URI can include arguments that don't affect the result set

These are always going to be query parameters. If the URL path is physically different you cannot guarantee the data is the same (and in our core Joomla response this is the case anyhow for the purposes of said checks - which is the more concrete thing - because ultimately people are parsing our responses).

I don't see first and last pages are not necessarily redundant even if they are the same page. Previous/Next definitely would be redundant because it's not actually a next/previous page if they don't exist

About square brackets encoding

Pagination links have unencoded square brackets, due to AbstractURI buildQuery method (https://github.com/joomla-framework/uri/blob/eed89d4997fcc52c08bba56116fa3ac4aef6a9db/src/AbstractUri.php#L345-L348) as it was already reported here

• #17365
• joomla-framework/uri#21
• #17966

so, to comply with JSON API spec, I chose to handle the encoding with an ad hoc protected method (I've also updated the com_config APIs to use it)
https://github.com/stefanoel/joomla-cms-wstest/blob/5df64298d7445ba3183923b00e65bcf5df434e1e/libraries/src/MVC/View/JsonApiView.php#L265

Now the links returned have encoded square brackets.
Any suggestions?

I wish to work on it

@stefanoel apologies this one dropped off my radar. are you willing to fix the conflicts here so i can do a round of testing and get it in please

sorry, now I'm stuck and I can't undestand the problem... I can't access my workstation and I'm not used to solve things from web interface... can you help please?

I have not tested this item.

When I try to apply the patch (Joomla! Patch Tester 3.0.0 beta 4):

Error
The file marked for modification does not exist: api/components/com_config/View/Application/JsonapiView.php

can i suggest you to use git commands to apply this patch
curl -L https://github.com/joomla/joomla-cms/pull/27005.diff | git apply

patchtester > Patch Tester 3.0.0 Beta 3 is still a WIP

anyway this pr needs conflict to be solved

@stefanoel can you fix conflict please

can i suggest you to use git commands to apply this patch
curl -L https://github.com/joomla/joomla-cms/pull/27005.diff | git apply

patchtester > Patch Tester 3.0.0 Beta 3 is still a WIP

anyway this pr needs conflict to be solved

Hi @alikon can you suggest how to do it from web interface? I'm working from home due to coronavirus emergency here in Italy, and I have to use a smartphone these days. I can't access my workstation...

@wilsonge Could you ckeck the conflict in the ApiController? Can it be that the pagination link is already ok with recently merged PR #27696 ? Or does it still need the change from this PR here in addition? I've stumpled over this when checking the merge conflicts here to 4.0-dev.

@stefanoel I've made a pull request in your repository: stefanoel#1. This will update your PR here so it is up to date with its base branch, and solves the merge conflicts shown here on GitHub.

@wilsonge Please review the changes in libraries/src/MVC/Controller/ApiController.php as I mentioned above.

@wilsonge @alikon Conflicts solved. Ready for review and testing.

great team-working
f***** covid19

@wilsonge Drone failing the 2nd time now. No idea if related.

This looks good to me! Thankyou!