Deserialization support?

Hi everybody and thanks for this awesome bundle.

Is there any plan to support deserialization? Are contributions in this direction welcomed?

Thanks.

What would be the use case?

The use case it to automatically get a PHP object graph from a JSON string following a normalized format.

For instance JSON API define PUT, POST and PATCH formats: http://jsonapi.org/format/ ("Updating" section). They are threads about write operations standardization on the HAL mailing list too.

Yep, makes perfectly sense. However the JsonApi hypermedia type is not supported yet... See #126 and #108

Topic about support for JSON Pointer, JSON Patch and JSON API on the Doctrine bug tracker: http://www.doctrine-project.org/jira/browse/DDC-2910

I already wrote a lib that supports patching graph objects using JSON Patch documents: https://gist.github.com/willdurand/31ac10e696b3197e7ec1. I will try to open source it, as some point..

Hateoas will support new specs, that's my plan since the beginning.

If you have ideas, or want to improve the lib, feel free to come up with something, either code or RFCs.

@willdurand Do you still plan to open-source that JSONPatch library ?

Hello,

I am working on a HAL client (json only) and it includes a basic support for JMS Serializer to deserialize hal resources into plain php object.

https://github.com/ekino/php-hal-client/blob/master/tests/HalClient/Deserialization/DeserializationTest.php

Feedbacks are welcomed

Hi, I'm working on a JSONPatch library:

https://github.com/victuxbb/jsonpatch

Currently I have a stable version but these days I will try to release another one without dependencies (I have a new idea of implementation base on the component of symfony PropertyAccessor)

@willdurand i see in your example working directly with the target object to apply operations, I was thinking about this and I believe that this will become a security problem. A client could launch operations like "add" or "replace" with a target "path" of a property object like "salt" and it should not be accessible...I don't know if I'm explaining me well... The specification in http://tools.ietf.org/html/rfc6902 explains about working against target json, Is for this that will be interesting a Deserialization of hateoas. About this security reasons will be necessary some "marks" or something else in the yaml or annotations to know what properties can be modified or added.

There is anyone working on the deserialization process? Thanks!!

Hi,

here is a basic deserialze implementation which works with anotations only. But maybe its a starting point for someone else: https://gist.github.com/mad654/93114d9cdc30ac5e9e339e53e9916fad

To get deserialization of embedded resources working the referencing property needs this annotation:

@JMS\Exclude(if="object !== null")

instead of

@JMS\Exclude

(compare to https://github.com/willdurand/Hateoas#embedding-resources)