@@ -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,29 @@ 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
+
213
+ # config/serializer/Book.yaml
214
+ App\E ntity\B ook:
215
+ attributes:
216
+ name:
217
+ groups: ['get', 'put']
218
+ author:
219
+ groups: ['get']
220
+ ` ` `
221
+
222
+ [/codeSelector]
223
+
199
224
The `name` and `author` properties will be included in the document generated during a `GET` operation because the configuration
200
225
defined at the resource level is inherited. However the document generated when a `PUT` request will be received will only
201
226
include the `name` property because of the specific configuration for this operation.
@@ -229,6 +254,8 @@ It is possible to embed related objects (in their entirety, or only some of thei
229
254
response through the use of serialization groups. By using the following serialization groups annotations (`@Groups`),
230
255
a JSON representation of the author is embedded in the book response :
231
256
257
+ [codeSelector]
258
+
232
259
` ` ` php
233
260
<?php
234
261
// api/src/Entity/Book.php
@@ -277,6 +304,28 @@ class Person
277
304
}
278
305
` ` `
279
306
307
+ ` ` ` yaml
308
+ # config/api/resources/Book.yaml
309
+ App\E ntity\B ook:
310
+ attributes:
311
+ normalization_context:
312
+ groups: ['book']
313
+ # config/serializer/Book.yaml
314
+ App\E ntity\B ook:
315
+ attributes:
316
+ name:
317
+ groups: ['book']
318
+ author:
319
+ groups: ['book']
320
+ # config/serializer/Person.yaml
321
+ App\E ntity\P erson:
322
+ attributes:
323
+ name:
324
+ groups: ['book']
325
+ ` ` `
326
+
327
+ [/codeSelector]
328
+
280
329
The generated JSON using previous settings is below :
281
330
282
331
` ` ` json
@@ -304,6 +353,8 @@ Instead of embedding relations in the main HTTP response, you may want [to "push
304
353
It is also possible to embed a relation in `PUT` and `POST` requests. To enable that feature, set the serialization groups
305
354
the same way as normalization. For example :
306
355
356
+ [codeSelector]
357
+
307
358
` ` ` php
308
359
<?php
309
360
// api/src/Entity/Book.php
@@ -319,6 +370,16 @@ class Book
319
370
}
320
371
` ` `
321
372
373
+ ` ` ` yaml
374
+ # config/api/resources/Book.yaml
375
+ App\E ntity\B ook:
376
+ attributes:
377
+ denormalization_context:
378
+ groups: ['book']
379
+ ` ` `
380
+
381
+ [/codeSelector]
382
+
322
383
The following rules apply when denormalizing embedded relations :
323
384
324
385
* If an `@id` key is present in the embedded resource, then the object corresponding to the given URI will be retrieved through
@@ -331,6 +392,8 @@ You can specify as many embedded relation levels as you want.
331
392
332
393
It is a common problem to have entities that reference other entities of the same type :
333
394
395
+ [codeSelector]
396
+
334
397
` ` ` php
335
398
<?php
336
399
// api/src/Entity/Person.php
@@ -364,13 +427,34 @@ class Person
364
427
365
428
// ...
366
429
}
430
+ ` ` `
367
431
432
+ ` ` ` yaml
433
+ # config/api/resources/Person.yaml
434
+ App\E ntity\P erson:
435
+ attributes:
436
+ normalization_context:
437
+ groups: ['person']
438
+ denormalization_context:
439
+ groups: ['person']
440
+
441
+ # config/serializer/Person.yaml
442
+ App\E ntity\P erson:
443
+ attributes:
444
+ name:
445
+ groups: ['person']
446
+ parent:
447
+ groups: ['person']
368
448
` ` `
369
449
450
+ [/codeSelector]
451
+
370
452
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
453
372
454
To force the **$parent** property to be used as an IRI, add an **#[ApiProperty(readableLink: false, writableLink: false)]** annotation:
373
455
456
+ [codeSelector]
457
+
374
458
` ` ` php
375
459
<?php
376
460
// api/src/Entity/Person.php
@@ -408,10 +492,36 @@ class Person
408
492
409
493
` ` `
410
494
495
+ ` ` ` yaml
496
+ # config/api/resources/Person.yaml
497
+ App\E ntity\P erson:
498
+ attributes:
499
+ normalization_context:
500
+ groups: ['person']
501
+ denormalization_context:
502
+ groups: ['person']
503
+ properties:
504
+ parent:
505
+ readableLink: false
506
+ writableLink: false
507
+
508
+ # config/serializer/Person.yaml
509
+ App\E ntity\P erson:
510
+ attributes:
511
+ name:
512
+ groups: ['person']
513
+ parent:
514
+ groups: ['person']
515
+ ` ` `
516
+
517
+ [/codeSelector]
518
+
411
519
# # Calculated Field
412
520
413
521
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
522
523
+ [codeSelector]
524
+
415
525
` ` ` php
416
526
<?php
417
527
@@ -470,12 +580,33 @@ class Greeting
470
580
}
471
581
` ` `
472
582
583
+ ` ` ` yaml
584
+ # config/api/resources/Greeting.yaml
585
+ App\E ntity\G reeting:
586
+ collectionOperations:
587
+ get:
588
+ normalization_context:
589
+ groups: 'greeting:collection:get'
590
+
591
+ # config/serializer/Greeting.yaml
592
+ App\E ntity\G reeting:
593
+ attributes:
594
+ id:
595
+ groups: 'greeting:collection:get'
596
+ getSum:
597
+ groups: 'greeting:collection:get'
598
+ ` ` `
599
+
600
+ [/codeSelector]
601
+
473
602
# # Changing the Serialization Context Dynamically
474
603
475
604
<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
605
477
606
Let's imagine a resource where most fields can be managed by any user, but some can be managed only by admin users :
478
607
608
+ [codeSelector]
609
+
479
610
` ` ` php
480
611
<?php
481
612
// api/src/Entity/Book.php
@@ -515,6 +646,26 @@ class Book
515
646
}
516
647
` ` `
517
648
649
+ ` ` ` yaml
650
+ # config/api/resources/Book.yaml
651
+ App\E ntity\B ook:
652
+ attributes:
653
+ normalization_context:
654
+ groups: ['book:output']
655
+ denormalization_context:
656
+ groups: ['book:input']
657
+
658
+ # config/serializer/Book.yaml
659
+ App\E ntity\B ook:
660
+ attributes:
661
+ active:
662
+ groups: ['book:output', 'admin:input']
663
+ name:
664
+ groups: ['book:output', 'book:input']
665
+ ` ` `
666
+
667
+ [/codeSelector]
668
+
518
669
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
670
dynamically add the `admin:input` value to deserialization groups in the `$context` array.
520
671
@@ -830,6 +981,8 @@ an IRI. A client that uses JSON-LD must send a second HTTP request to retrieve i
830
981
You can configure API Platform to embed the JSON-LD context in the root document by adding the `jsonld_embed_context`
831
982
attribute to the `#[ApiResource]` annotation:
832
983
984
+ [codeSelector]
985
+
833
986
` ` ` php
834
987
<?php
835
988
// api/src/Entity/Book.php
@@ -845,6 +998,16 @@ class Book
845
998
}
846
999
` ` `
847
1000
1001
+ ` ` ` yaml
1002
+ # config/api/resources/Book.yaml
1003
+ App\E ntity\B ook:
1004
+ attributes:
1005
+ normalization_context:
1006
+ jsonld_embed_context: true
1007
+ ` ` `
1008
+
1009
+ [/codeSelector]
1010
+
848
1011
The JSON output will now include the embedded context :
849
1012
850
1013
` ` ` json
0 commit comments