You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+76-72Lines changed: 76 additions & 72 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,4 @@
1
-
# Dynamic REST
2
-
3
-
[](https://gitter.im/dynamic-rest/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
2) From within the repository root, start the demo server:
119
+
2. From within the repository root, start the demo server:
116
120
117
121
```bash
118
122
make serve
119
123
```
120
124
121
-
3) Visit `localhost:9002` in your browser.
125
+
3. Visit `localhost:9002` in your browser.
122
126
123
-
4) To load sample fixture data, run `make fixtures` and restart the server.
127
+
4. To load sample fixture data, run `make fixtures` and restart the server.
124
128
125
129
# Features
126
130
@@ -215,7 +219,7 @@ In DREST, the requirement to eagerly load (or "sideload") relationships can be e
215
219
For example, in order to fetch a user and sideload their groups:
216
220
217
221
```
218
-
-->
222
+
-->
219
223
GET /users/1/?include[]=groups.*
220
224
<--
221
225
200 OK
@@ -247,7 +251,7 @@ With DREST, it is possible to sideload as many relationships as you'd like, as d
247
251
For example, to obtain the user with groups, locations, and groups' locations all sideloaded in the same response:
248
252
249
253
```
250
-
-->
254
+
-->
251
255
GET /users/1/?include[]=groups.location.*&include[]=location.*
252
256
<--
253
257
200 OK
@@ -282,7 +286,7 @@ For example, to obtain the user with groups, locations, and groups' locations al
282
286
283
287
## Embedded relationships
284
288
285
-
If you want your relationships loaded eagerly but don't want them sideloaded in the top-level, you can instruct your serializer to embed relationships instead.
289
+
If you want your relationships loaded eagerly but don't want them sideloaded in the top-level, you can instruct your serializer to embed relationships instead.
286
290
287
291
In that case, the demo serializer above would look like this:
288
292
@@ -303,7 +307,7 @@ class UserSerializer(DynamicModelSerializer):
303
307
... and the call above would return a response with relationships embedded in place of the usual ID representation:
304
308
305
309
```
306
-
-->
310
+
-->
307
311
GET /users/1/?include[]=groups.*
308
312
<--
309
313
200 OK
@@ -329,7 +333,7 @@ In DREST, sideloading is the default because it can produce much smaller payload
329
333
330
334
For example, if you requested a list of 10 users along with their groups, and those users all happened to be in the same groups, the embedded variant would represent each group 10 times. The sideloaded variant would only represent a particular group once, regardless of the number of times that group is referenced.
331
335
332
-
## Inclusions
336
+
## Inclusions
333
337
334
338
You can use the `include[]` feature not only to sideload relationships, but also to load basic fields that are marked "deferred".
335
339
@@ -346,7 +350,7 @@ class UserSerializer(DynamicModelSerializer):
groups = DynamicRelationField('GroupSerializer', many=True)
352
356
@@ -373,7 +377,7 @@ This field will only be returned if requested:
373
377
}
374
378
```
375
379
376
-
Note that `include[]=personal_statement` does not have a `.` following the field name as in the previous examples for embedding and sideloading relationships. This allows us to differentiate between cases where we have a deferred relationship and want to include the relationship IDs as opposed to including and also sideloading the relationship.
380
+
Note that `include[]=personal_statement` does not have a `.` following the field name as in the previous examples for embedding and sideloading relationships. This allows us to differentiate between cases where we have a deferred relationship and want to include the relationship IDs as opposed to including and also sideloading the relationship.
377
381
378
382
For example, if the user had a deferred "events" relationship, passing `include[]=events` would return an "events" field populated by event IDs, passing `include[]=events.` would sideload or embed the events themselves, and by default, only a link to the events would be returned. This can be useful for large has-many relationships.
379
383
@@ -453,7 +457,7 @@ You can filter a user by his name (exact match):
453
457
... or a partial match:
454
458
455
459
```
456
-
-->
460
+
-->
457
461
GET /users/?filter{name.icontains}=jo
458
462
<--
459
463
200 OK
@@ -516,13 +520,13 @@ You can filter a user by his name (exact match):
516
520
517
521
The sky is the limit! DREST supports just about every basic filtering scenario and operator that you can use in Django:
518
522
519
-
* in
520
-
* icontains
521
-
* istartswith
522
-
* range
523
-
* lt
524
-
* gt
525
-
...
523
+
- in
524
+
- icontains
525
+
- istartswith
526
+
- range
527
+
- lt
528
+
- gt
529
+
...
526
530
527
531
See the [full list here](dynamic_rest/filters.py#L153-L176).
528
532
@@ -558,8 +562,8 @@ DREST adds that in:
558
562
## Optimizations
559
563
560
564
Supporting nested sideloading and filtering is expensive and can lead to very poor query performance if implemented naively.
561
-
DREST uses Django's [Prefetch](https://docs.djangoproject.com/en/1.9/ref/models/querysets/#django.db.models.Prefetch) object to prevent N+1 query situations and guarantee that your API is performant.
562
-
We also optimize the serializer layer to ensure that the conversion of model objects into JSON is as fast as possible.
565
+
DREST uses Django's [Prefetch](https://docs.djangoproject.com/en/1.9/ref/models/querysets/#django.db.models.Prefetch) object to prevent N+1 query situations and guarantee that your API is performant.
566
+
We also optimize the serializer layer to ensure that the conversion of model objects into JSON is as fast as possible.
563
567
564
568
How fast is it? Here are some [benchmarks](benchmarks) that compare DREST response time to DRF response time. DREST out-performs DRF on every benchmark:
0 commit comments