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
Having the ability to use a different serialization context than JMS Serializer would be very beneficial. The use case is when you have an object graph that has the same object represented two different ways. Here is an example, and pardon the length but I feel at least one example would make discussion easier.
You have two objects: Post and User. A Post has a property called "author" which points to a User. Here is some pseudo-ish code for these two classes:
class Post {
/**
* @Type("User")
* @Groups({"posts"})
*/
var $author;
/**
* @Type("string")
* @Groups({"posts"})
*/
var $title;
/**
* @Type("string")
* @Groups({"posts"})
*/
var $content;
}
class User {
/**
* @Type("string")
* @Groups({"users", "posts", "embedded"})
*/
var $id;
/**
* @Type("string")
* @Groups({"users", "embedded"})
*/
var $name;
/**
* @Type("array")
* @Groups({"users", "embedded"})
*/
var $preferences;
}
You have two RESTful routes on your API for this content:
/api/posts/{id}
/api/users/{id}
Say you have the following two objects in your database:
Post:
{
"id": 1,
"author": {
"$ref" : "User",
"$id" : "1",
"$db" : "blog"
},
"title": "An Example Post",
"content": "<p>This is a great post.</p>"
}
{
"id": 1,
"author": {
"id": 1
},
"title": "An Example Post",
"content": "<p>This is a great post.</p>",
"_embedded": {
"author": {
"id": 1,
"name": "John Doe",
"preferences": {
"lang": "en-US"
}
}
}
}
And, you want to update that Post to be User 2 by sending PUT /api/posts/1:
{
"id": 1,
"author": {
"id": 2
},
"title": "An Example Post",
"content": "<p>This is a great post.</p>"
}
This would work flawlessly if you could pass a SerializationContext to Hateoas Bundle that uses the "embedded" serialization group and separate one to JMS Serializer Bundle that uses the "posts" serialization group. The reason this configuration would be nice is that JMS will silently discard any modified data, but seamlessly update which User the Post references on $author.
As it stands, since Hateoas uses the context from JMS the serialization groups you send apply to all objects in the graph. So, you either exclude the author from the embedded data and force the API user to make a separate request to get the user or use a separate route to handle updating the references, such as: /api/posts/{id}/author.
The text was updated successfully, but these errors were encountered:
Having the ability to use a different serialization context than JMS Serializer would be very beneficial. The use case is when you have an object graph that has the same object represented two different ways. Here is an example, and pardon the length but I feel at least one example would make discussion easier.
You have two objects: Post and User. A Post has a property called "author" which points to a User. Here is some pseudo-ish code for these two classes:
You have two RESTful routes on your API for this content:
Say you have the following two objects in your database:
Post:
User:
You make a GET to /api/posts/1 and get:
And, you want to update that Post to be User 2 by sending PUT /api/posts/1:
This would work flawlessly if you could pass a SerializationContext to Hateoas Bundle that uses the "embedded" serialization group and separate one to JMS Serializer Bundle that uses the "posts" serialization group. The reason this configuration would be nice is that JMS will silently discard any modified data, but seamlessly update which User the Post references on $author.
As it stands, since Hateoas uses the context from JMS the serialization groups you send apply to all objects in the graph. So, you either exclude the author from the embedded data and force the API user to make a separate request to get the user or use a separate route to handle updating the references, such as: /api/posts/{id}/author.
The text was updated successfully, but these errors were encountered: