Problem
Our current URLs for occurrence search is base64 encoded JSON. That cannot be fiddled with as a human (like changing a year). Even if it wasn't base64 encoded it would still be very awkward to change anything. And it is very useful to be able to fiddle with the URL. As a developer at least this is something many of us do frequently.
Reason it is like this
The hosted portals support search by predicates. And that cannot easily be serialised to something as simple as what we have in APIv1.
Change suggestion
Most queries are very simple and could be serialised to an APIv1 GET query string. So we could do so in most cases, and then break into the more complex search strings as needed. E.g.
simple: apiv1 style: country=US&year=1900,2000
but country NOT USA and identifiedBy LIKE "*humboldt*" cannot fit into v1, but could then be JSON or similar less human friendly.
And finally we could use (possible short lived) IDs for very large queries that doesn't fit into the URL.
Problem Our current URLs for occurrence search is base64 encoded JSON. That cannot be fiddled with as a human (like changing a year). Even if it wasn't base64 encoded it would still be very awkward to change anything. And it is very useful to be able to fiddle with the URL. As a developer at least this is something many of us do frequently.
Reason it is like this The hosted portals support search by predicates. And that cannot easily be serialised to something as simple as what we have in APIv1.
Change suggestion Most queries are very simple and could be serialised to an APIv1 GET query string. So we could do so in most cases, and then break into the more complex search strings as needed. E.g.
country NOT USA and identifiedBy LIKE "*humboldt*"
cannot fit into v1, but could then be JSON or similar less human friendly.