400 Bad Request errors received on some paginated requests

Hi,

I’ve successfully implemented the paginated functionality on the api, but
when I added in the new sorting feature on the invoice fetching api, I get
this error:

Invalid sort order “-updated_at?”. Valid sort orders: created_at, updated_at

When I looked at the URL requested (which was for page 2), it was :

https://api.freeagent.com/v2/invoices?page=2&per_page=100%3F&sort=-updated_at

The headers returned for the first url requested
(https://api.freeagent.com/v2/invoices?sort=-updated_at&per_page=100), the
Link header was

Link:
https://api.freeagent.com/v2/invoices?page=2&per_page=100%3F&sort=-updated_at;
rel=‘next’,
https://api.freeagent.com/v2/invoices?page=8&per_page=100%3F&sort=-updated_at;
rel=‘last’

So the api is returning urls with a %3F in them that shouldn’t be there,
and then that was used as the url to query for the 2nd page, resulting in
the above error.

Cheers,
Stella

I’ve since changed the order of the GET params on the initial query
from https://api.freeagent.com/v2/invoices?sort=-updated_at&per_page=100 to https://api.freeagent.com/v2/invoices?per_page=100&sort=-updated_at
and now I get the same 400 Bad Request error for that page too.

StellaOn Sunday, July 27, 2014 1:04:48 AM UTC+1, ste...@annertech.com wrote:

Hi,

I’ve successfully implemented the paginated functionality on the api, but
when I added in the new sorting feature on the invoice fetching api, I get
this error:

Invalid sort order “-updated_at?”. Valid sort orders: created_at,

updated_at

When I looked at the URL requested (which was for page 2), it was :

https://api.freeagent.com/v2/invoices?page=2&per_page=100%3F&sort=-updated_at

The headers returned for the first url requested (
https://api.freeagent.com/v2/invoices?sort=-updated_at&per_page=100), the
Link header was

Link: <
https://api.freeagent.com/v2/invoices?page=2&per_page=100%3F&sort=-updated_at>;
rel=‘next’, <
https://api.freeagent.com/v2/invoices?page=8&per_page=100%3F&sort=-updated_at>;
rel=‘last’

So the api is returning urls with a %3F in them that shouldn’t be there,
and then that was used as the url to query for the 2nd page, resulting in
the above error.

Cheers,
Stella

I’ve now “hacked” my code so that if a url is returned containing
“per_page=100&” it is stripped and added to the end of the url as
“&per_page=100” and that is now getting me past the errors. However, it
looks like the “per_page” GET param has to be the last param in the URL,
and that the url returned by FreeAgent doesn’t follow this (broken) rule.

StellaOn Sunday, July 27, 2014 1:11:55 AM UTC+1, ste...@annertech.com wrote:

I’ve since changed the order of the GET params on the initial query from
https://api.freeagent.com/v2/invoices?sort=-updated_at&per_page=100 to
https://api.freeagent.com/v2/invoices?per_page=100&sort=-updated_at and
now I get the same 400 Bad Request error for that page too.

Stella

On Sunday, July 27, 2014 1:04:48 AM UTC+1, ste...@annertech.com wrote:

Hi,

I’ve successfully implemented the paginated functionality on the api, but
when I added in the new sorting feature on the invoice fetching api, I get
this error:

Invalid sort order “-updated_at?”. Valid sort orders: created_at,

updated_at

When I looked at the URL requested (which was for page 2), it was :

https://api.freeagent.com/v2/invoices?page=2&per_page=100%3F&sort=-updated_at

The headers returned for the first url requested (
https://api.freeagent.com/v2/invoices?sort=-updated_at&per_page=100),
the Link header was

Link: <
https://api.freeagent.com/v2/invoices?page=2&per_page=100%3F&sort=-updated_at>;
rel=‘next’, <
https://api.freeagent.com/v2/invoices?page=8&per_page=100%3F&sort=-updated_at>;
rel=‘last’

So the api is returning urls with a %3F in them that shouldn’t be there,
and then that was used as the url to query for the 2nd page, resulting in
the above error.

Cheers,
Stella

Hi Stella,

I’m afraid I can’t reproduce the error you’re seeing. Could it be that the
code you’re using to build the URL parameters is appending an extra “?” or
“&” on the end of the parameters?

When our code builds the pagination URLs it includes the parameters you
originally supplied. If the per_page parameter is supplied by your code as
“per_page=100&” or “per_page=100?” and if the sort parameter is supplied as
“sort=-updated_at?” or “sort=-updated_at&” then those parameters will be
returned as part of the page urls. Our code doesn’t try to sanitise the
params sent by your code. Our code doesn’t mind what order the parameters
are sent in but if there are extra “&” and “?” characters then it won’t be
able to parse some of the combinations, which is why it seems like the API
cares about the order. In particular extra chars don’t upset the per_page
parameter but do upset the sort parameter.

Cheers,

GraemeOn 27 July 2014 01:16, stella@annertech.com wrote:

I’ve now “hacked” my code so that if a url is returned containing
“per_page=100&” it is stripped and added to the end of the url as
“&per_page=100” and that is now getting me past the errors. However, it
looks like the “per_page” GET param has to be the last param in the URL,
and that the url returned by FreeAgent doesn’t follow this (broken) rule.

Stella

On Sunday, July 27, 2014 1:11:55 AM UTC+1, ste...@annertech.com wrote:

I’ve since changed the order of the GET params on the initial query from
https://api.freeagent.com/v2/invoices?sort=-updated_at&per_page=100 to
https://api.freeagent.com/v2/invoices?per_page=100&sort=-updated_at and
now I get the same 400 Bad Request error for that page too.

Stella

On Sunday, July 27, 2014 1:04:48 AM UTC+1, ste...@annertech.com wrote:

Hi,

I’ve successfully implemented the paginated functionality on the api,
but when I added in the new sorting feature on the invoice fetching api, I
get this error:

Invalid sort order “-updated_at?”. Valid sort orders: created_at,

updated_at

When I looked at the URL requested (which was for page 2), it was :

https://api.freeagent.com/v2/invoices?page=2&per_page=100%

3F&sort=-updated_at

The headers returned for the first url requested (
https://api.freeagent.com/v2/invoices?sort=-updated_at&per_page=100),
the Link header was

Link: <https://api.freeagent.com/v2/invoices?page=2&per_page=100%
3F&sort=-updated_at>; rel=‘next’, <https://api.freeagent.com/v2/
invoices?page=8&per_page=100%3F&sort=-updated_at>; rel=‘last’

So the api is returning urls with a %3F in them that shouldn’t be there,
and then that was used as the url to query for the 2nd page, resulting in
the above error.

Cheers,
Stella


You received this message because you are subscribed to the Google Groups
“FreeAgent API” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to freeagent_api+unsubscribe@googlegroups.com.
To post to this group, send email to freeagent_api@googlegroups.com.
Visit this group at http://groups.google.com/group/freeagent_api.
For more options, visit https://groups.google.com/d/optout.

Graeme Boyd
Engineering Manager

Web. freeagent.com http://www.freeagent.com/ Blog. The FreeAgent Blog - FreeAgent
Twitter. @freeagent https://twitter.com/#!/freeagent Facebook.
FreeAgent | Edinburgh

40 Torphichen Street, Edinburgh, EH3 8JB
FreeAgent Central Ltd. Registered in sunny Scotland SC316774

Hi Graeme,

If you’re confident it’s not an issue in your code, then perhaps the issue
lies in the PHP-OAuth2 library I’m using, cos my code just parses the url
from the header and requests that without any mods.

StellaOn Monday, July 28, 2014 11:42:41 PM UTC+1, ste...@annertech.com wrote:

Hi Graeme,

The first url requested by my application is:
https://api.freeagent.com/v2/invoices?sort=-updated_at&per_page=100

It returns 100 results and the following headers:
[headers] => Array
(
[0] => HTTP/1.1 200 OK
[1] => Server: nginx
[2] => Date: Sat, 26 Jul 2014 23:58:37 GMT
[3] => Content-Type: application/json; charset=utf-8
[4] => Transfer-Encoding: chunked
[5] => Connection: keep-alive
[6] => Status: 200 OK
[7] => Link: <
https://api.freeagent.com/v2/invoices?page=2&per_page=100%3F&sort=-updated_at>;
rel=‘next’, <
https://api.freeagent.com/v2/invoices?page=8&per_page=100%3F&sort=-updated_at>;
rel=‘last’
[8] => ETag: “be4f0320a904c3d8e382b25e2780641d”
[9] => Last-Modified: Wed, 23 Jul 2014 17:09:03 GMT
[10] => Cache-Control: max-age=0, private, must-revalidate
[11] => X-UA-Compatible: IE=Edge,chrome=1
[12] => X-Request-Id: 53582a0440f14cd43a104c087364d4ab
[13] => X-Runtime: 1.275021
[14] => X-Rev: 7d4383
[15] => X-Host: web1-gc
[16] => Strict-Transport-Security: max-age=3600;
[17] =>
[18] =>
)

You can see the link returned in the headers for the next page is
https://api.freeagent.com/v2/invoices?page=2&per_page=100%3F&sort=-updated_at

When I try to fetch that url -
https://api.freeagent.com/v2/invoices?page=2&per_page=100%3F&sort=-updated_at
I get the 400 Bad Request error as reported above.

Stella

On Monday, July 28, 2014 11:31:38 AM UTC+1, Graeme Boyd wrote:

Hi Stella,

I’m afraid I can’t reproduce the error you’re seeing. Could it be that
the code you’re using to build the URL parameters is appending an extra “?”
or “&” on the end of the parameters?

When our code builds the pagination URLs it includes the parameters you
originally supplied. If the per_page parameter is supplied by your code as
“per_page=100&” or “per_page=100?” and if the sort parameter is supplied as
“sort=-updated_at?” or “sort=-updated_at&” then those parameters will be
returned as part of the page urls. Our code doesn’t try to sanitise the
params sent by your code. Our code doesn’t mind what order the parameters
are sent in but if there are extra “&” and “?” characters then it won’t be
able to parse some of the combinations, which is why it seems like the API
cares about the order. In particular extra chars don’t upset the per_page
parameter but do upset the sort parameter.

Cheers,

Graeme

On 27 July 2014 01:16, ste...@annertech.com wrote:

I’ve now “hacked” my code so that if a url is returned containing
“per_page=100&” it is stripped and added to the end of the url as
“&per_page=100” and that is now getting me past the errors. However, it
looks like the “per_page” GET param has to be the last param in the URL,
and that the url returned by FreeAgent doesn’t follow this (broken) rule.

Stella

On Sunday, July 27, 2014 1:11:55 AM UTC+1, ste...@annertech.com wrote:

I’ve since changed the order of the GET params on the initial query
from https://api.freeagent.com/v2/invoices?sort=-updated_
at&per_page=100 to https://api.freeagent.com/v2/invoices?
per_page=100&sort=-updated_at and now I get the same 400 Bad Request
error for that page too.

Stella

On Sunday, July 27, 2014 1:04:48 AM UTC+1, ste...@annertech.com wrote:

Hi,

I’ve successfully implemented the paginated functionality on the api,
but when I added in the new sorting feature on the invoice fetching api, I
get this error:

Invalid sort order “-updated_at?”. Valid sort orders: created_at,

updated_at

When I looked at the URL requested (which was for page 2), it was :

https://api.freeagent.com/v2/invoices?page=2&per_page=100%

3F&sort=-updated_at

The headers returned for the first url requested (
https://api.freeagent.com/v2/invoices?sort=-updated_at&per_page=100),
the Link header was

Link: <https://api.freeagent.com/v2/invoices?page=2&per_page=100%
3F&sort=-updated_at>; rel=‘next’, <https://api.freeagent.com/v2/
invoices?page=8&per_page=100%3F&sort=-updated_at>; rel=‘last’

So the api is returning urls with a %3F in them that shouldn’t be
there, and then that was used as the url to query for the 2nd page,
resulting in the above error.

Cheers,
Stella


You received this message because you are subscribed to the Google
Groups “FreeAgent API” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to freeagent_ap...@googlegroups.com.
To post to this group, send email to freeag...@googlegroups.com.
Visit this group at http://groups.google.com/group/freeagent_api.
For more options, visit https://groups.google.com/d/optout.


Graeme Boyd
Engineering Manager

Web. freeagent.com http://www.freeagent.com/ Blog. The FreeAgent Blog - FreeAgent
Twitter. @freeagent https://twitter.com/#!/freeagent Facebook.
FreeAgent | Edinburgh

40 Torphichen Street, Edinburgh, EH3 8JB
FreeAgent Central Ltd. Registered in sunny Scotland SC316774

Hi Stella,

That’s great you were able to find the issue.

Cheers,

GraemeOn 29 July 2014 00:00, stella@annertech.com wrote:

Hi Graeme,

I dug around in the PHP-OAuth2 library code and found the issue. They’re
not quite stringent enough in their checking on a particular conditional
and so my request was being handled incorrectly. However, I was able to
invoke it in a different manner to bypass that bit of code and it now works
fine. So it looks like the issue lies in the library I’m using, sorry
about that.

Cheers,
Stella

On Monday, July 28, 2014 11:49:03 PM UTC+1, ste...@annertech.com wrote:

Hi Graeme,

If you’re confident it’s not an issue in your code, then perhaps the
issue lies in the PHP-OAuth2 library I’m using, cos my code just parses the
url from the header and requests that without any mods.

Stella

On Monday, July 28, 2014 11:42:41 PM UTC+1, ste...@annertech.com wrote:

Hi Graeme,

The first url requested by my application is: https://api.freeagent.com/
v2/invoices?sort=-updated_at&per_page=100

It returns 100 results and the following headers:
[headers] => Array
(
[0] => HTTP/1.1 200 OK
[1] => Server: nginx
[2] => Date: Sat, 26 Jul 2014 23:58:37 GMT
[3] => Content-Type: application/json; charset=utf-8
[4] => Transfer-Encoding: chunked
[5] => Connection: keep-alive
[6] => Status: 200 OK
[7] => Link: <https://api.freeagent.com/v2/
invoices?page=2&per_page=100%3F&sort=-updated_at>; rel=‘next’, <
https://api.freeagent.com/v2/invoices?page=8&per_page=100%
3F&sort=-updated_at>; rel=‘last’
[8] => ETag: “be4f0320a904c3d8e382b25e2780641d”
[9] => Last-Modified: Wed, 23 Jul 2014 17:09:03 GMT
[10] => Cache-Control: max-age=0, private, must-revalidate
[11] => X-UA-Compatible: IE=Edge,chrome=1
[12] => X-Request-Id: 53582a0440f14cd43a104c087364d4ab
[13] => X-Runtime: 1.275021
[14] => X-Rev: 7d4383
[15] => X-Host: web1-gc
[16] => Strict-Transport-Security: max-age=3600;
[17] =>
[18] =>
)

You can see the link returned in the headers for the next page is
https://api.freeagent.com/v2/invoices?page=2&per_page=100%
3F&sort=-updated_at

When I try to fetch that url - https://api.freeagent.com/v2/
invoices?page=2&per_page=100%3F&sort=-updated_at I get the 400 Bad
Request error as reported above.

Stella

On Monday, July 28, 2014 11:31:38 AM UTC+1, Graeme Boyd wrote:

Hi Stella,

I’m afraid I can’t reproduce the error you’re seeing. Could it be that
the code you’re using to build the URL parameters is appending an extra “?”
or “&” on the end of the parameters?

When our code builds the pagination URLs it includes the parameters you
originally supplied. If the per_page parameter is supplied by your code as
“per_page=100&” or “per_page=100?” and if the sort parameter is supplied as
“sort=-updated_at?” or “sort=-updated_at&” then those parameters will be
returned as part of the page urls. Our code doesn’t try to sanitise the
params sent by your code. Our code doesn’t mind what order the parameters
are sent in but if there are extra “&” and “?” characters then it won’t be
able to parse some of the combinations, which is why it seems like the API
cares about the order. In particular extra chars don’t upset the per_page
parameter but do upset the sort parameter.

Cheers,

Graeme

On 27 July 2014 01:16, ste...@annertech.com wrote:

I’ve now “hacked” my code so that if a url is returned containing
“per_page=100&” it is stripped and added to the end of the url as
“&per_page=100” and that is now getting me past the errors. However, it
looks like the “per_page” GET param has to be the last param in the URL,
and that the url returned by FreeAgent doesn’t follow this (broken) rule.

Stella

On Sunday, July 27, 2014 1:11:55 AM UTC+1, ste...@annertech.com wrote:

I’ve since changed the order of the GET params on the initial query
from https://api.freeagent.com/v2/invoices?sort=-updated_at&
per_page=100 to https://api.freeagent.com/v2/invoices?per_
page=100&sort=-updated_at and now I get the same 400 Bad Request
error for that page too.

Stella

On Sunday, July 27, 2014 1:04:48 AM UTC+1, ste...@annertech.com wrote:

Hi,

I’ve successfully implemented the paginated functionality on the
api, but when I added in the new sorting feature on the invoice fetching
api, I get this error:

Invalid sort order “-updated_at?”. Valid sort orders: created_at,

updated_at

When I looked at the URL requested (which was for page 2), it was :

https://api.freeagent.com/v2/invoices?page=2&per_page=100%3F

&sort=-updated_at

The headers returned for the first url requested (
https://api.freeagent.com/v2/invoices?sort=-updated_at&per_page=100),
the Link header was

Link: <https://api.freeagent.com/v2/invoices?page=2&per_page=100%3
F&sort=-updated_at>; rel=‘next’, <https://api.freeagent.com/v2/
invoices?page=8&per_page=100%3F&sort=-updated_at>; rel=‘last’

So the api is returning urls with a %3F in them that shouldn’t be
there, and then that was used as the url to query for the 2nd page,
resulting in the above error.

Cheers,
Stella


You received this message because you are subscribed to the Google
Groups “FreeAgent API” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to freeagent_ap...@googlegroups.com.
To post to this group, send email to freeag...@googlegroups.com.
Visit this group at http://groups.google.com/group/freeagent_api.
For more options, visit https://groups.google.com/d/optout.


Graeme Boyd
Engineering Manager

Web. freeagent.com http://www.freeagent.com/ Blog.
The FreeAgent Blog - FreeAgent
Twitter. @freeagent https://twitter.com/#!/freeagent Facebook.
FreeAgent | Edinburgh

40 Torphichen Street, Edinburgh, EH3 8JB
FreeAgent Central Ltd. Registered in sunny Scotland SC316774


You received this message because you are subscribed to the Google Groups
“FreeAgent API” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to freeagent_api+unsubscribe@googlegroups.com.
To post to this group, send email to freeagent_api@googlegroups.com.
Visit this group at http://groups.google.com/group/freeagent_api.
For more options, visit https://groups.google.com/d/optout.

Graeme Boyd
Engineering Manager

Web. freeagent.com http://www.freeagent.com/ Blog. The FreeAgent Blog - FreeAgent
Twitter. @freeagent https://twitter.com/#!/freeagent Facebook.
FreeAgent | Edinburgh

40 Torphichen Street, Edinburgh, EH3 8JB
FreeAgent Central Ltd. Registered in sunny Scotland SC316774

Hi Graeme,

I dug around in the PHP-OAuth2 library code and found the issue. They’re
not quite stringent enough in their checking on a particular conditional
and so my request was being handled incorrectly. However, I was able to
invoke it in a different manner to bypass that bit of code and it now works
fine. So it looks like the issue lies in the library I’m using, sorry
about that.

Cheers,
StellaOn Monday, July 28, 2014 11:49:03 PM UTC+1, ste...@annertech.com wrote:

Hi Graeme,

If you’re confident it’s not an issue in your code, then perhaps the issue
lies in the PHP-OAuth2 library I’m using, cos my code just parses the url
from the header and requests that without any mods.

Stella

On Monday, July 28, 2014 11:42:41 PM UTC+1, ste...@annertech.com wrote:

Hi Graeme,

The first url requested by my application is:
https://api.freeagent.com/v2/invoices?sort=-updated_at&per_page=100

It returns 100 results and the following headers:
[headers] => Array
(
[0] => HTTP/1.1 200 OK
[1] => Server: nginx
[2] => Date: Sat, 26 Jul 2014 23:58:37 GMT
[3] => Content-Type: application/json; charset=utf-8
[4] => Transfer-Encoding: chunked
[5] => Connection: keep-alive
[6] => Status: 200 OK
[7] => Link: <
https://api.freeagent.com/v2/invoices?page=2&per_page=100%3F&sort=-updated_at>;
rel=‘next’, <
https://api.freeagent.com/v2/invoices?page=8&per_page=100%3F&sort=-updated_at>;
rel=‘last’
[8] => ETag: “be4f0320a904c3d8e382b25e2780641d”
[9] => Last-Modified: Wed, 23 Jul 2014 17:09:03 GMT
[10] => Cache-Control: max-age=0, private, must-revalidate
[11] => X-UA-Compatible: IE=Edge,chrome=1
[12] => X-Request-Id: 53582a0440f14cd43a104c087364d4ab
[13] => X-Runtime: 1.275021
[14] => X-Rev: 7d4383
[15] => X-Host: web1-gc
[16] => Strict-Transport-Security: max-age=3600;
[17] =>
[18] =>
)

You can see the link returned in the headers for the next page is
https://api.freeagent.com/v2/invoices?page=2&per_page=100%3F&sort=-updated_at

When I try to fetch that url -
https://api.freeagent.com/v2/invoices?page=2&per_page=100%3F&sort=-updated_at
I get the 400 Bad Request error as reported above.

Stella

On Monday, July 28, 2014 11:31:38 AM UTC+1, Graeme Boyd wrote:

Hi Stella,

I’m afraid I can’t reproduce the error you’re seeing. Could it be that
the code you’re using to build the URL parameters is appending an extra “?”
or “&” on the end of the parameters?

When our code builds the pagination URLs it includes the parameters you
originally supplied. If the per_page parameter is supplied by your code as
“per_page=100&” or “per_page=100?” and if the sort parameter is supplied as
“sort=-updated_at?” or “sort=-updated_at&” then those parameters will be
returned as part of the page urls. Our code doesn’t try to sanitise the
params sent by your code. Our code doesn’t mind what order the parameters
are sent in but if there are extra “&” and “?” characters then it won’t be
able to parse some of the combinations, which is why it seems like the API
cares about the order. In particular extra chars don’t upset the per_page
parameter but do upset the sort parameter.

Cheers,

Graeme

On 27 July 2014 01:16, ste...@annertech.com wrote:

I’ve now “hacked” my code so that if a url is returned containing
“per_page=100&” it is stripped and added to the end of the url as
“&per_page=100” and that is now getting me past the errors. However, it
looks like the “per_page” GET param has to be the last param in the URL,
and that the url returned by FreeAgent doesn’t follow this (broken) rule.

Stella

On Sunday, July 27, 2014 1:11:55 AM UTC+1, ste...@annertech.com wrote:

I’ve since changed the order of the GET params on the initial query
from https://api.freeagent.com/v2/invoices?sort=-updated_
at&per_page=100 to https://api.freeagent.com/v2/invoices?
per_page=100&sort=-updated_at and now I get the same 400 Bad Request
error for that page too.

Stella

On Sunday, July 27, 2014 1:04:48 AM UTC+1, ste...@annertech.com wrote:

Hi,

I’ve successfully implemented the paginated functionality on the api,
but when I added in the new sorting feature on the invoice fetching api, I
get this error:

Invalid sort order “-updated_at?”. Valid sort orders: created_at,

updated_at

When I looked at the URL requested (which was for page 2), it was :

https://api.freeagent.com/v2/invoices?page=2&per_page=100%

3F&sort=-updated_at

The headers returned for the first url requested (
https://api.freeagent.com/v2/invoices?sort=-updated_at&per_page=100),
the Link header was

Link: <https://api.freeagent.com/v2/invoices?page=2&per_page=100%
3F&sort=-updated_at>; rel=‘next’, <https://api.freeagent.com/v2/
invoices?page=8&per_page=100%3F&sort=-updated_at>; rel=‘last’

So the api is returning urls with a %3F in them that shouldn’t be
there, and then that was used as the url to query for the 2nd page,
resulting in the above error.

Cheers,
Stella


You received this message because you are subscribed to the Google
Groups “FreeAgent API” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to freeagent_ap...@googlegroups.com.
To post to this group, send email to freeag...@googlegroups.com.
Visit this group at http://groups.google.com/group/freeagent_api.
For more options, visit https://groups.google.com/d/optout.


Graeme Boyd
Engineering Manager

Web. freeagent.com http://www.freeagent.com/ Blog.
The FreeAgent Blog - FreeAgent
Twitter. @freeagent https://twitter.com/#!/freeagent Facebook.
FreeAgent | Edinburgh

40 Torphichen Street, Edinburgh, EH3 8JB
FreeAgent Central Ltd. Registered in sunny Scotland SC316774

Hi Graeme,

The first url requested by my application
is: https://api.freeagent.com/v2/invoices?sort=-updated_at&per_page=100

It returns 100 results and the following headers:
[headers] => Array
(
[0] => HTTP/1.1 200 OK
[1] => Server: nginx
[2] => Date: Sat, 26 Jul 2014 23:58:37 GMT
[3] => Content-Type: application/json; charset=utf-8
[4] => Transfer-Encoding: chunked
[5] => Connection: keep-alive
[6] => Status: 200 OK
[7] => Link:
https://api.freeagent.com/v2/invoices?page=2&per_page=100%3F&sort=-updated_at;
rel=‘next’,
https://api.freeagent.com/v2/invoices?page=8&per_page=100%3F&sort=-updated_at;
rel=‘last’
[8] => ETag: “be4f0320a904c3d8e382b25e2780641d”
[9] => Last-Modified: Wed, 23 Jul 2014 17:09:03 GMT
[10] => Cache-Control: max-age=0, private, must-revalidate
[11] => X-UA-Compatible: IE=Edge,chrome=1
[12] => X-Request-Id: 53582a0440f14cd43a104c087364d4ab
[13] => X-Runtime: 1.275021
[14] => X-Rev: 7d4383
[15] => X-Host: web1-gc
[16] => Strict-Transport-Security: max-age=3600;
[17] =>
[18] =>
)

You can see the link returned in the headers for the next page is
https://api.freeagent.com/v2/invoices?page=2&per_page=100%3F&sort=-updated_at

When I try to fetch that url -
https://api.freeagent.com/v2/invoices?page=2&per_page=100%3F&sort=-updated_at
I get the 400 Bad Request error as reported above.

StellaOn Monday, July 28, 2014 11:31:38 AM UTC+1, Graeme Boyd wrote:

Hi Stella,

I’m afraid I can’t reproduce the error you’re seeing. Could it be that
the code you’re using to build the URL parameters is appending an extra “?”
or “&” on the end of the parameters?

When our code builds the pagination URLs it includes the parameters you
originally supplied. If the per_page parameter is supplied by your code as
“per_page=100&” or “per_page=100?” and if the sort parameter is supplied as
“sort=-updated_at?” or “sort=-updated_at&” then those parameters will be
returned as part of the page urls. Our code doesn’t try to sanitise the
params sent by your code. Our code doesn’t mind what order the parameters
are sent in but if there are extra “&” and “?” characters then it won’t be
able to parse some of the combinations, which is why it seems like the API
cares about the order. In particular extra chars don’t upset the per_page
parameter but do upset the sort parameter.

Cheers,

Graeme

On 27 July 2014 01:16, <ste...@annertech.com <javascript:>> wrote:

I’ve now “hacked” my code so that if a url is returned containing
“per_page=100&” it is stripped and added to the end of the url as
“&per_page=100” and that is now getting me past the errors. However, it
looks like the “per_page” GET param has to be the last param in the URL,
and that the url returned by FreeAgent doesn’t follow this (broken) rule.

Stella

On Sunday, July 27, 2014 1:11:55 AM UTC+1, ste...@annertech.com wrote:

I’ve since changed the order of the GET params on the initial query from
https://api.freeagent.com/v2/invoices?sort=-updated_at&per_page=100 to
https://api.freeagent.com/v2/invoices?per_page=100&sort=-updated_at and
now I get the same 400 Bad Request error for that page too.

Stella

On Sunday, July 27, 2014 1:04:48 AM UTC+1, ste...@annertech.com wrote:

Hi,

I’ve successfully implemented the paginated functionality on the api,
but when I added in the new sorting feature on the invoice fetching api, I
get this error:

Invalid sort order “-updated_at?”. Valid sort orders: created_at,

updated_at

When I looked at the URL requested (which was for page 2), it was :

https://api.freeagent.com/v2/invoices?page=2&per_page=100%

3F&sort=-updated_at

The headers returned for the first url requested (
https://api.freeagent.com/v2/invoices?sort=-updated_at&per_page=100),
the Link header was

Link: <https://api.freeagent.com/v2/invoices?page=2&per_page=100%
3F&sort=-updated_at>; rel=‘next’, <https://api.freeagent.com/v2/
invoices?page=8&per_page=100%3F&sort=-updated_at>; rel=‘last’

So the api is returning urls with a %3F in them that shouldn’t be
there, and then that was used as the url to query for the 2nd page,
resulting in the above error.

Cheers,
Stella


You received this message because you are subscribed to the Google Groups
“FreeAgent API” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to freeagent_ap...@googlegroups.com <javascript:>.
To post to this group, send email to freeag...@googlegroups.com
<javascript:>.
Visit this group at http://groups.google.com/group/freeagent_api.
For more options, visit https://groups.google.com/d/optout.


Graeme Boyd
Engineering Manager

Web. freeagent.com http://www.freeagent.com/ Blog. The FreeAgent Blog - FreeAgent
Twitter. @freeagent https://twitter.com/#!/freeagent Facebook.
FreeAgent | Edinburgh

40 Torphichen Street, Edinburgh, EH3 8JB
FreeAgent Central Ltd. Registered in sunny Scotland SC316774