mirror of
https://github.com/peeringdb/peeringdb.git
synced 2024-05-11 05:55:09 +00:00
ba6f9b6432
* use new peeringdb client (1.0.0) for pdb_load_data sync (#599) * drop django-mobi for lack of py3/dj2 support (#492) remove django-forms-bootstrap for lack of py3/dj2 support (#492) * black formatted * django2.2 and py3 upgrade (#492) * drop ixlans (#21) ui and api changes * drop local_asn (#168) * org search (#193) * phone number validation (#50) * implement help text tooltips (#228) * Mark own ASN as transit-free (#394) * py3 fix for `pdb_migrate_ixlans` command when writing migration report * pdb_migrate_ixlans: properly handle py3 Runtime error if ixlan dict changes during iteration * set rest DEFAULT_SCHEMA_CLASS to coreapi to fix swagger apidocs fix migration 0027 missing from facsimile manifest * fix swagger doc strings * fix tests that were broken from api doc fixes * fix UniqueFieldValidator for netixlan ipaddress validation that broke during django/drf upgrade * fix org merge tool layout issues * travis config * update pipfile and lock * black formatting * update travis dist * beta mode banner (#411) * add beta banner template (#411) * automatically scheduled sync may not always be on, add a flag that lets us reflect that state in the beta banner message clean up beta banner implementation (#411) * add tests for beta banner (#411)
121 lines
3.2 KiB
Markdown
121 lines
3.2 KiB
Markdown
Retrieves a list of objects
|
|
|
|
### Querying
|
|
|
|
You may query the resultset by passing field names as url parameters
|
|
|
|
### Numeric Queries
|
|
|
|
On numeric fields you can suffix the field names with the following filters:
|
|
|
|
- \_\_lt : less-than
|
|
- \_\_lte : less-than-equal
|
|
- \_\_gt : greater-than
|
|
- \_\_gte : greater-than-equal
|
|
- \_\_in : value inside set of values (comma separated)
|
|
|
|
**examples**
|
|
|
|
?<field_name>__lt=10
|
|
?<field_name>__in=1,10
|
|
|
|
### String Queries
|
|
|
|
On string fields you can suffix the field names with the following filters:
|
|
|
|
- \_\_contains : field value contains specified value
|
|
- \_\_startswith : field value starts with specified value
|
|
- \_\_in : value contained inside set of values (comma separated)
|
|
|
|
**examples**
|
|
|
|
?<field_name>__contains=something
|
|
?<field_name>__in=this,that
|
|
|
|
All string filtering operations are case-insensitive
|
|
|
|
### Since
|
|
|
|
|
|
You can use the since argument with a unix timestamp (seconds) to retrieve all
|
|
objects updated since then. Note that this result will contain objects that were
|
|
deleted in that timeframe as well - you can spot them by checking for status "deleted"
|
|
|
|
**example**
|
|
|
|
?since=1443414678
|
|
|
|
### Nested data
|
|
|
|
Any field ending in the suffix **_set** is a list of objects in a relationship with the parent
|
|
object, you can expand those lists with the 'depth' parameter as explained below.
|
|
|
|
The naming schema of the field will always tell you which type of object the set is holding
|
|
and will correspond with the object's endpoint on the API
|
|
|
|
<object_type>_set
|
|
|
|
So a set called 'net_set' will hold Network objects (api endpoint /net)
|
|
|
|
### Depth
|
|
|
|
Nested sets will not be loaded (any field ending with the _set suffix) unless the 'depth'
|
|
parameter is passed in the request URL.
|
|
|
|
Depth can be one of three values:
|
|
|
|
- 1 : expand sets into ids (slow)
|
|
- 2 : expand sets into objects (slower)
|
|
- 0 : dont expand sets at all (default behaviour)
|
|
|
|
**example**
|
|
|
|
?depth=1
|
|
|
|
### Cached Responses
|
|
|
|
Any request that does not require lookups will be served a cached result. Cache is updated approximately every 15 minutes.
|
|
|
|
You can spot cached responses by checking for the "generated" property inside the "meta" object.
|
|
|
|
"meta" : {
|
|
// the cached data was last regenerated at this time (epoch)
|
|
"generated" : 1456121358.6301942
|
|
}
|
|
|
|
**examples**
|
|
|
|
will serve a cached result:
|
|
|
|
?depth=2
|
|
|
|
will serve a live result:
|
|
|
|
?id__in=1,2
|
|
|
|
### Resultset limit
|
|
|
|
Any request that does lookup queries and has it's **depth** parameter specified will have a result limit of 250 entries, any entries past this limit will be truncated, at which point you either should be more specific with your query or use the skip and limit parameters to page through the result set
|
|
|
|
**examples**
|
|
|
|
will serve a live result and a maximum of 250 rows at a time:
|
|
|
|
?updated__gt=2011-01-01&depth=1
|
|
|
|
will serve a live result and will not be truncated:
|
|
|
|
?updated__gt=2011-01-01
|
|
|
|
will serve a cached result and will not be truncated:
|
|
|
|
?depth=1
|
|
|
|
### Pagination
|
|
|
|
Use the skip and limit parameters to page through results
|
|
|
|
?updated__gt=2011-01-01&depth=1&limit=250 - first page
|
|
?updated__gt=2011-01-01&depth=1&limit=250&skip=250 - second page
|
|
?updated__gt=2011-01-01&depth=1&limit=250&skip=500 - third page
|