[ChikkaChiChi]

If you live in one framework and always will, then I see your point. But if you want to have the ability to code out native solutions, use other tools where other tools may be more appropriate, or discipline your projects to be a little less biased, then asking PHP to parse JSON is not a huge buy.

That's how we've done it here and the modularization it has provided us has been incredible. PHP's json_encode and json_decode are also quite fast.

[marrs]

I don't really get your reasoning there. Forms are the mechanism for making parameterised requests over HTTP. If REST is your platform then it makes sense to start with them, regardless of any framework you are using.

I'm not saying using JSON as an envelope won't work - it is clearly working for you - just that I wouldn't start there, and I can't see that you couldn't work with the request object directly.

[ChikkaChiChi]

Maybe I'm not understanding our disagreement, but if I am incorrect please help me understand what I am missing.

In your preferred way, data is exchanged over HTTP which uses percent encoding to pass data. I'm stating that a serialized object, in this case JSON, provides more benefit.

Both require overhead to encode and decode, but I believe that serializing your data allows for a more consistent exchange that (provided I am understanding how you post and retrieve data) actually may reduce size, increase the variance of what can be transmitted, and remove specific limitations that HTTP may encounter.

I'm genuinely curious if I am missing something.

[marrs]

First of all, I don't want to oversell this. I'm not overly precious about it and I'm not saying that having started with HTTP as a platform I wouldn't add JSON later.

I'm sure I could find myself in a position where I would want to standardise on JSON as a container for requests/responses, though see my last paragraph about Atom.

That said, my instinctive reaction against using JSON as an envelope is that it adds a layer of abstraction (and potential obfuscation) that I don't see an immediate benefit for. It may hark back to my experiences with SOAP. My mantra is to exploit the existing protocol to its fullest before extending it, and to do the simplest thing before adding complexity.

Let's presuming we're still at a basic level of interaction through a website. Treating something as a form with fields such as name="user[email]", name="user[password]", name="user[telephone][mobile]" etc, seems more discoverable to me, as a developer at least.

For one thing, I know there is no JSON translation layer to go through. For another, I can get a server to generate a form that I can use to test the interface quickly and easily. To do the same with JSON would require me to have some JS intercepting the submit event so that it can convert the contents to JSON before posting. So now I can't use a terminal based browser to do my testing. Which means maybe I can't automate some testing strategy so easily.

If we're talking about a more sophisticated RESTful API, I would probably choose ATOM over JSON, because ATOM is built on XML and therefore is defined by a schema and can be interpreted by the browser. Specifically, it provides the rel attribute for discoverability. JSON payloads can implement this too, but you have to choose your extension.

In fairness, if I were doing a RESTful API, I'd probably be thinking about being able to implement interfaces for ATOM, JSON, and HTML, plus whatever cool new thing is just around the corner.

[ChikkaChiChi]

Thanks for clarifying.

I'll agree that your way definitely provides less abstraction, and my viewpoint doesn't perceive jt in that way. That being said, I've made a similar case against ORMs, so I understand your position.