Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Custom SerializationContext #34

Open
josephdpurcell opened this issue Oct 6, 2014 · 0 comments
Open

Support Custom SerializationContext #34

josephdpurcell opened this issue Oct 6, 2014 · 0 comments

Comments

@josephdpurcell
Copy link

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>"
}

User:

{
    "id": 1,
    "name": "John Doe",
    "preferences": {
        "lang": "en-US"
    }
},
{
    "id": 2,
    "name": "Jane Doe",
    "preferences": {
        "lang": "en-US"
    }
}

You make a GET to /api/posts/1 and get:

{
    "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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants