I phrased this question in a specific manner, but I'm more interested in how one generally approaches the problem of figuring out the input parameters for an API. I am trying to filter by date_created__range for the option endpoint in this API and I can't figure out how it wants the date range formatted. They specify that they use the ISO-8601 format, but I have tried all the following to no avail:
https://www.courtlistener.com/api/rest/v3/opinions/?date_created__range=2020-12-01--20-12-10
https://www.courtlistener.com/api/rest/v3/opinions/?date_created__range=2020-12-01..20-12-10
https://www.courtlistener.com/api/rest/v3/opinions/?date_created__range=2020-12-01/20-12-10
I've also tried with those date ranges reversed. All of these fail with the message "Enter a valid date/time." I've even tried downloading the source code for the API and searching through it, but I haven't found anything relevant to this question. How would you go about figuring this out?
I tried this and it might be what you're looking for!
https://www.courtlistener.com/api/rest/v3/opinions/?date_created__range=2013-01-01T00:00:00Z,2013-01-03T00:00:00Z
For reference on process, I just copied one of the dates they used in their example date_modified query
curl https://www.courtlistener.com/api/rest/v3/dockets/?court__date_modified__gt=2013-01-01T00:00:00Z and added a second one separated by a comma, since you had already tried dashes, periods, and a slash.
Related
I have what I think is a fairly common task. I have a REST API that provides access to an Alert resource. When I query for Alerts, I want only the most recent ones, I don't want the entire universe (except for the first call I make). The natural candidate for the 'freshness' criteria is the Timestamp datatype in SQL. So, the first call I want to do something like this:
https://localhost/api/alerts
Which returns everything. My code will then scan the returned results, find the maximum Timestamp, and the next call will look like this:
https://localhost/api/alerts/<maximumTimestamp>
The issue is: what datatype should I use to pass the Timestamp? I don't like using a long because it seems like an interpretation of the byte[8] field that could get me into trouble on some machines. I thought about encoding it as a Base64 string, but that seems like a lot of work back and fourth (although, in a URL, everything is going to be encoded).
Has anyone else tried to deal with passing timestamps to reduce the size of the REST API result sets?
I have a list of Exchanges (extract shown below) and I want to give a user WRITE permissions to all but those containing Invoice in the name. Here an extract of the list of Exchanges as an example:
E.BankAccount.Commands
E.BankAccount.Commands.Confirmations
E.BankAccount.Commands.Errors
E.BankAccount.Events
E.Customer.Commands
E.Customer.Commands.Confirmations
E.Customer.Commands.Errors
E.Customer.Events
E.Invoice.Commands
E.Invoice.Commands.Confirmations
E.Invoice.Commands.Errors
E.Payment.Commands
E.Payment.Commands.Confirmations
E.Payment.Commands.Errors
E.Payment.EventsEvents.test
So I can write a regex like this:
E\.(BankAccount|Customer|Payment)\.[a-zA-Z.]+
This works but since I have more than 100 different types it is a lot to type and almost impossible to maintain. Better would be to have a regex which excludes invoice. I tried a couple of things but without any look, e.g.
E\.([a-zA-Z.]+|?!Invoice)\.[a-zA-Z.]+ or
E\.([a-zA-Z.]+|?!(Invoice))\.[a-zA-Z.]+
But that is all syntactically wrong. Another strategy could be to reverse the result of the expression e.g. use
E\.(Invoice)\.[a-zA-Z.]+
and then somehow reverse the entire result but I could not figure out how!
I am not using regex very often so I can't find any better solution then the first one which is impracticable in my production environment.
Does anybody have more experience and a solution to that problem?? Any help would be greatly appreciated!
I'm using Umbraco v7.2 for a site, and have run into a highly entertaining issue trying to search for things using the External Searcher by a date of ranges.
If I perform a Lucene search using the examine management search tools in the backoffice, I get results using this query:
{(+__NodeTypeAlias:bookingperiod)} AND startDate:2016-03-01T00\:00\:00
Subsequently, I KNOW that I can get results that include this date in a range. However, what's highly entertaining, quite puzzling and really rather frustrating, is that if I use a range query, I get no results. Here's the syntax:
{(+__NodeTypeAlias:bookingperiod)} AND +(startDate:[2016-02-28T00:00:00 TO 2016-03-20T00:00:00])
Now, in the interests of clarity, I've tried escaping the colon characters in the dates, the dashes in the dates and both, but it makes no difference at all. Can anyone explain to me where I'm going wrong?
Thanks!
I ran into this issue a while back, not sure why though, but changing to the format :"yyyyMMddHHmmss" helped, might be something with the parser.
So the query becomes:
+__NodeTypeAlias:bookingperiod AND +startDate:[20160228000000 TO 20160320000000]
I am working on a wrapper for an API, and one of the endpoints returns data that doesn't have the same results each time.
What is a good strategy to test that the endpoint is still valid?
This is a general question, although I am mostly interested in getting this to work in Python.
You need to define what you actually expect from the result. What are the statements that always hold for the result?
Popular candidates/examples are
it is valid JSON/HTML/XML
it contains certain substrings
it has certain "fields"
certain fields can be parsed as a date using a specific format, and the resulting date is within +/-1h of now.
I'm using the Yodlee REST API and am trying to retrieve all user transactions in giving dates.
When calling executeUserSearchRequest with the following params, I get only 13 transactions instead of more.
transactionSearchRequest.containerType=all
transactionSearchRequest.higherFetchLimit=500
transactionSearchRequest.lowerFetchLimit=1
transactionSearchRequest.resultRange.startNumber=1
transactionSearchRequest.resultRange.endNumber=500
transactionSearchRequest.searchClients.clientId=1
transactionSearchRequest.searchClients.clientName=DataSearchService
transactionSearchRequest.searchFilter.currencyCode=ILS
transactionSearchRequest.ignoreUserInput=true
transactionSearchRequest.searchFilter.transactionSplitType=ALL_TRANSACTION
transactionSearchRequest.searchFilter.postDateRange.fromDate=01-01-2014
transactionSearchRequest.searchFilter.postDateRange.toDate=04-01-2014
Following this didn't help, since it's not updated.
Update: I've corrected the dates, it was a typo here and didn't appear on the actual request.
Dates sent to Yodlee are not ISO standard and can be done as
MM-dd-yyyy
or
MM-dd-yyyyTHH:mm:ss.000Z.
e.g. :
"transactionSearchRequest.searchFilter.postDateRange.fromDate":"03-22-2014T00:00:00.000Z",
"transactionSearchRequest.searchFilter.postDateRange.toDate":"06-21-2014T23:59:59.000Z",
HOWEVER outbound dates are ISO standard e.g.
"postDate" : "2014-06-20T00:00:00-0700",
The REST API needs a lot of work, this is just one of the many issues we have come across. Don't get me started the on the lacking documentation, the incorrect documentation, ignoring HTTP protocols, mixed serialization approaches, java exceptions over the wire...
IMO It is not good enough for a paid for service
:(
transactionSearchRequest.searchFilter.postDateRange.fromDate=04-01-2014
transactionSearchRequest.searchFilter.postDateRange.toDate=01-01-2014
Can you try swap those date range values and try? Are you sure these date range has more transactions.
Could you please change the fromDate/toDate's value, as it should in chronological order. And the date format is in format as MM-DD-YYYY.
First remove the two date criteria lines and see what you get. If you get>13 txns then try the below:
Assuming you want txns between 01-Jan-2014 to 01-Apr-2014. Do something like this:
transactionSearchRequest.searchFilter.postDateRange.fromDate="01-01-2014T00:00:000Z"
transactionSearchRequest.searchFilter.postDateRange.toDate="04-01-2014T00:00:000Z"
There seems to be a mismatch between your existing txns dates and search criteria you are providing. It could be timezone issue also, so please consider that.