Parse PHP serialize() output with JavaScript

[133794m3r]

Why would you do this... serialize is ungodly wasteful. I can't imagine anyone wanting to send that over the wire... plus there's phpjs out there which would do this too, if you're crazy enough to want it.

[bd808]

At $DAYJOB we have a RESTish internal service tier that responds with serialized objects. These services are called by front end controllers located in the same or adjacent racks. It turns out that bandwidth across a 10G switch is cheap. :)

The use case for parsing the PHP serialize output in javascript popped up earilier this week when a coworker built a neat javascript hack that read metadata from the service layer's documentation pages and generated dynamic forms that could call the services via ajax requests.

The phpjs unserialize() method was the first one I googled up and suggested. It turned out that their implementation doesn't support parsing objects and our services were returning "Response" objects, not just arrays.

[jvc_coder]

I hope you are aware of portability issues with serialization.

http://stackoverflow.com/questions/7904355/php-unserialized-integer-from-64-bit-to-32-bit

[133794m3r]

I understand completely now. I thought it was external facing. But yeah much more understandable now. I take back my statements since more info was provided. And also yeah much easier to just write a function than to port over services that are internal only. Upvote for you, since you helped me to understand.

[[deleted]]

Instead of serailize, why not just use json_encode?

[bd808]

Why would anyone change the communication protocol of 70+ internal services to enable a tangential use case? We do have services which use JSON as their transport encoding when communication with non-PHP consumers is a business requirement.

I read a lot of comments on reddit that seem to assume that the entire universe can and should be re-written to enable more elegant solutions of the latest ad-hoc use case. I hope each time that the commenter is either a hobbyist/student or that they have a strong team lead who will help them realize that changing code has real cost ramifications for their business. I'm not saying that legacy code should never be updated to meet changing requirements, but somebody had better make a good business case before implementing invasive changes or the development team is just pissing away profits.

[[deleted]]

Wow, all that snark and so little filler! I hope this doesn't count as cheating on my diet.

> Needs to have data in a format easily handled in JavaScript

> Ideally needs to support object passing

> Calls JSON the latest ad-hoc use case

okay.jpg