Pagination inputToken and pageSize Path Support about smithy

[rumenvasilev]

Can you try to bypass the validation with @suppress(["PaginatedTrait"]) and see if that would work for you?

[mtdowling]

Do you really need to make the token nested on input? It seems like a bad idea to me since if you ever wanted to support something like HTTP bindings, you couldn't use a GET request and put the token in the query string (those only support top-level members).

[hunoz]

Can you try to bypass the validation with @suppress(["PaginatedTrait"]) and see if that would work for you?

That seems to result in it failing to build with this error:

 Projection source failed: java.util.NoSuchElementException: No value present
     [java] java.util.NoSuchElementException: No value present

Do you really need to make the token nested on input? It seems like a bad idea to me since if you ever wanted to support something like HTTP bindings, you couldn't use a GET request and put the token in the query string (those only support top-level members).

Yes, we do this to group any current and future pagination attributes, since a request has other attributes. With this operation, we have no plan of supporting GET requests as the filters can get quite large.

[haydenbaker]

Like Michael stated, it's a bad idea. Additionally, if we start adding support for nesting/pathing in more places, we'll get more requests to add it elsewhere (say, in the http traits).

Closing this as not planned.