@@ -162,6 +162,8 @@ level ignored.
162
162
163
163
In the following example we use different serialization groups for the `GET` and `PUT` operations :
164
164
165
+ [codeSelector]
166
+
165
167
` ` ` php
166
168
<?php
167
169
// api/src/Entity/Book.php
@@ -196,6 +198,32 @@ class Book
196
198
}
197
199
` ` `
198
200
201
+ ` ` ` yaml
202
+ # config/api/resources/Book.yaml
203
+ App\E ntity\B ook:
204
+ attributes:
205
+ normalization_context:
206
+ groups: ['get']
207
+ itemOperations:
208
+ get: ~
209
+ put:
210
+ normalization_context:
211
+ groups: ['put']
212
+ properties:
213
+ name:
214
+ groups: ['get', 'put']
215
+
216
+ # config/serializer/Book.yaml
217
+ App\E ntity\B ook:
218
+ attributes:
219
+ name:
220
+ groups: ['get', 'put']
221
+ author:
222
+ groups: ['get']
223
+ ` ` `
224
+
225
+ [/codeSelector]
226
+
199
227
The `name` and `author` properties will be included in the document generated during a `GET` operation because the configuration
200
228
defined at the resource level is inherited. However the document generated when a `PUT` request will be received will only
201
229
include the `name` property because of the specific configuration for this operation.
@@ -229,6 +257,8 @@ It is possible to embed related objects (in their entirety, or only some of thei
229
257
response through the use of serialization groups. By using the following serialization groups annotations (`@Groups`),
230
258
a JSON representation of the author is embedded in the book response :
231
259
260
+ [codeSelector]
261
+
232
262
` ` ` php
233
263
<?php
234
264
// api/src/Entity/Book.php
@@ -277,6 +307,28 @@ class Person
277
307
}
278
308
` ` `
279
309
310
+ ` ` ` yaml
311
+ # config/api/resources/Book.yaml
312
+ App\E ntity\B ook:
313
+ attributes:
314
+ normalization_context:
315
+ groups: ['book']
316
+ # config/serializer/Book.yaml
317
+ App\E ntity\B ook:
318
+ attributes:
319
+ name:
320
+ groups: ['book']
321
+ author:
322
+ groups: ['book']
323
+ # config/serializer/Person.yaml
324
+ App\E ntity\P erson:
325
+ attributes:
326
+ name:
327
+ groups: ['book']
328
+ ` ` `
329
+
330
+ [/codeSelector]
331
+
280
332
The generated JSON using previous settings is below :
281
333
282
334
` ` ` json
@@ -304,6 +356,8 @@ Instead of embedding relations in the main HTTP response, you may want [to "push
304
356
It is also possible to embed a relation in `PUT` and `POST` requests. To enable that feature, set the serialization groups
305
357
the same way as normalization. For example :
306
358
359
+ [codeSelector]
360
+
307
361
` ` ` php
308
362
<?php
309
363
// api/src/Entity/Book.php
@@ -319,6 +373,16 @@ class Book
319
373
}
320
374
` ` `
321
375
376
+ ` ` ` yaml
377
+ # config/api/resources/Book.yaml
378
+ App\E ntity\B ook:
379
+ attributes:
380
+ denormalization_context:
381
+ groups: ['book']
382
+ ` ` `
383
+
384
+ [/codeSelector]
385
+
322
386
The following rules apply when denormalizing embedded relations :
323
387
324
388
* If an `@id` key is present in the embedded resource, then the object corresponding to the given URI will be retrieved through
@@ -331,6 +395,8 @@ You can specify as many embedded relation levels as you want.
331
395
332
396
It is a common problem to have entities that reference other entities of the same type :
333
397
398
+ [codeSelector]
399
+
334
400
` ` ` php
335
401
<?php
336
402
// api/src/Entity/Person.php
@@ -364,13 +430,34 @@ class Person
364
430
365
431
// ...
366
432
}
433
+ ` ` `
434
+
435
+ ` ` ` yaml
436
+ # config/api/resources/Person.yaml
437
+ App\E ntity\P erson:
438
+ attributes:
439
+ normalization_context:
440
+ groups: ['person']
441
+ denormalization_context:
442
+ groups: ['person']
367
443
444
+ # config/serializer/Person.yaml
445
+ App\E ntity\P erson:
446
+ attributes:
447
+ name:
448
+ groups: ['person']
449
+ parent:
450
+ groups: ['person']
368
451
` ` `
369
452
453
+ [/codeSelector]
454
+
370
455
The problem here is that the **$parent** property become automatically an embedded object. Besides, the property won't be shown on the OpenAPI view.
371
456
372
457
To force the **$parent** property to be used as an IRI, add an **#[ApiProperty(readableLink: false, writableLink: false)]** annotation:
373
458
459
+ [codeSelector]
460
+
374
461
` ` ` php
375
462
<?php
376
463
// api/src/Entity/Person.php
@@ -408,10 +495,36 @@ class Person
408
495
409
496
` ` `
410
497
498
+ ` ` ` yaml
499
+ # config/api/resources/Person.yaml
500
+ App\E ntity\P erson:
501
+ attributes:
502
+ normalization_context:
503
+ groups: ['person']
504
+ denormalization_context:
505
+ groups: ['person']
506
+ properties:
507
+ parent:
508
+ readableLink: false
509
+ writableLink: false
510
+
511
+ # config/serializer/Person.yaml
512
+ App\E ntity\P erson:
513
+ attributes:
514
+ name:
515
+ groups: ['person']
516
+ parent:
517
+ groups: ['person']
518
+ ` ` `
519
+
520
+ [/codeSelector]
521
+
411
522
# # Calculated Field
412
523
413
524
Sometimes you need to expose calculated fields. This can be done by leveraging the groups. This time not on a property, but on a method.
414
525
526
+ [codeSelector]
527
+
415
528
` ` ` php
416
529
<?php
417
530
@@ -470,12 +583,33 @@ class Greeting
470
583
}
471
584
` ` `
472
585
586
+ ` ` ` yaml
587
+ # config/api/resources/Greeting.yaml
588
+ App\E ntity\G reeting:
589
+ collectionOperations:
590
+ get:
591
+ normalization_context:
592
+ groups: 'greeting:collection:get'
593
+
594
+ # config/serializer/Greeting.yaml
595
+ App\E ntity\G reeting:
596
+ attributes:
597
+ id:
598
+ groups: 'greeting:collection:get'
599
+ getSum:
600
+ groups: 'greeting:collection:get'
601
+ ` ` `
602
+
603
+ [/codeSelector]
604
+
473
605
# # Changing the Serialization Context Dynamically
474
606
475
607
<p align="center" class="symfonycasts"><a href="https://symfonycasts.com/screencast/api-platform-security/service-decoration?cid=apip"><img src="../distribution/images/symfonycasts-player.png" alt="Context Builder & Service Decoration screencast"><br>Watch the Context Builder & Service Decoration screencast</a></p>
476
608
477
609
Let's imagine a resource where most fields can be managed by any user, but some can be managed only by admin users :
478
610
611
+ [codeSelector]
612
+
479
613
` ` ` php
480
614
<?php
481
615
// api/src/Entity/Book.php
@@ -515,6 +649,26 @@ class Book
515
649
}
516
650
` ` `
517
651
652
+ ` ` ` yaml
653
+ # config/api/resources/Book.yaml
654
+ App\E ntity\B ook:
655
+ attributes:
656
+ normalization_context:
657
+ groups: ['book:output']
658
+ denormalization_context:
659
+ groups: ['book:input']
660
+
661
+ # config/serializer/Book.yaml
662
+ App\E ntity\B ook:
663
+ attributes:
664
+ active:
665
+ groups: ['book:output', 'admin:input']
666
+ name:
667
+ groups: ['book:output', 'book:input']
668
+ ` ` `
669
+
670
+ [/codeSelector]
671
+
518
672
All entry points are the same for all users, so we should find a way to detect if the authenticated user is an admin, and if so
519
673
dynamically add the `admin:input` value to deserialization groups in the `$context` array.
520
674
@@ -830,6 +984,8 @@ an IRI. A client that uses JSON-LD must send a second HTTP request to retrieve i
830
984
You can configure API Platform to embed the JSON-LD context in the root document by adding the `jsonld_embed_context`
831
985
attribute to the `#[ApiResource]` annotation:
832
986
987
+ [codeSelector]
988
+
833
989
` ` ` php
834
990
<?php
835
991
// api/src/Entity/Book.php
@@ -845,6 +1001,16 @@ class Book
845
1001
}
846
1002
` ` `
847
1003
1004
+ ` ` ` yaml
1005
+ # config/api/resources/Book.yaml
1006
+ App\E ntity\B ook:
1007
+ attributes:
1008
+ normalization_context:
1009
+ jsonld_embed_context: true
1010
+ ` ` `
1011
+
1012
+ [/codeSelector]
1013
+
848
1014
The JSON output will now include the embedded context :
849
1015
850
1016
` ` ` json
0 commit comments