I can see a big use case for SF2 being a REST SOA for applications. I can see JSON being a common approach for communication inside this. As a modularised framework, SF2 doesn't do JSON transactions natively, but it is easy to educate it. It would also likely to be a REST API, but REST is implemented via FOS REST bundle, so there is little point in going into that in this article. The FOS module is widely used and seems to have an active development cycle. There are new releases quite frequently.
SF2 does have quite good POST validation libraries and transcoders (so your business logic only needs to consume Entities not raw arrays). The Validation is described in the SF2 docs, and various howtos online, so I will omit that from this article as well. The input validation can't read JSON blocks by default.
If there really isn't a library for this, I will need to write one. Engineering requires that this library exists, but not that it is public.
The requirements are longer than just parse JSON, as this will reduce the cost of the business logic, and increase quality faster. Likewise the business logic shouldn't care if a client does requests in XML, the framework should deal with the translation.
- Process JSON POSTs or PUTs from clients (its a business logic decision what to do with the request);
- Deal with any UTF-8 issues;
- Deal with anything to do with dates, so business logic gets a DateTime object or similar. JSON is abit poor with dates;
- Deal with objects and arrays of objects;
- Must not crash on empty requests (I guess a HTTP400 error);
- The resultant entities classes will need to be configurable;
- Route configuration is not part of this feature;
- PHP does ship with a JSON decoder and encoder.
- It is possible to set the content in the Request object, via replace() for old versions of SF2. This feature has been removed. For new version you can make a new Request object.
- The single purpose JSON actions should be isolated from requests they shouldn't need to handle. The point of a flexible and extendible routing layer is all the specific and valid routes can be skimpy on input validation. e.g. JSON POST actions don't need to think about GET, a GET will be routed to a different action.
- Most POST readers require a name for the POST data. In many B2B? systems, I have standardised on 'xml', I guess this could be 'json'.
- The Entities will probably need to implement one of the interfaces, as you do for ORM. Work should be pushed into the parser, so Entities don't all need to implement an unpack function.
This is the first time I have addressed this inside SF2, but this is not a new requirement. There must be an existing library (although there is no need for it to be public).
- Although only partially relevant, SF2 does have Symfony\Component\Serializer\Encoder\JsonDecode?. M. Noback does have a concept 1, but this would not be portable in a heterogeneous environment.
- Qandidate have published 2 or code 3.
- W Durand 4.
- As related work, A Quaile's library 5 does JSON to array of objects.
- I find this odd. I tried repeating the search without mentioning Symfony2, I get back articles with good quality pseudo code; no libraries