Best approach to send complex data to the server

[NotionCommotion]

All good with sending single dimensional form data to the server using application/x-www-form-urlencoded, and having PHP convert it into an array.  Also, good with sending simple arrays using [].  But then I find myself needing to send a deeper object to the server .  For example, I have a form with three text inputs simpleFormName 1, 2, and 3 plus some deeper object.

Array
(
    [simpleFormName1] => bla
    [simpleFormName2] => bla
    [simpleFormName3] => bla
    [deeperObject] => Array
        (
            [0] => Array
                (
                    [prop1] => bla
                    [prop2] => true
                    [data] => Array
                        (
                            [0] => Array
                                (
                                    [p1] => 321
                                    [p2] => 123
                                )

                            [1] => Array
                                (
                                    [p1] => 121
                                    [p2] => 423
                                )

                            [2] => Array
                                (
                                    [p1] => 221
                                    [p2] => 133
                                )

                        )

                )

            [1] => Array
                (
                    [prop1] => blabla
                    [prop2] => false
                    [data] => Array
                        (
                            [0] => Array
                                (
                                    [p1] => 222
                                    [p2] => 443
                                )

                            [1] => Array
                                (
                                    [p1] => 321
                                    [p2] => 213
                                )

                            [2] => Array
                                (
                                    [p1] => 111
                                    [p2] => 421
                                )

                        )

                )

        )

)

 

I see at least four options:

1. Come up with naming structure which "flattens" the data.  I have used this approach in the past, but it quickly becomes difficult to manage and I don't want to do so.
2. Not use PHP's POST and and instead use Content-Type: application/json and file_get_contents(php://input) and json_decode the entire request server side.
3. Use PHP's POST and urlencoding but make deeperObject a string using JSON.stringify and json_decode this one field server side.
4. Urlencode the entire object.

simpleFormName1=bla&simpleFormName2=bla&simpleFormName3=bla&deeperObject%5B0%5D%5Bprop1%5D=bla&deeperObject%5B0%5D%5Bprop2%5D=true&deeperObject%5B0%5D%5Bdata%5D%5B0%5D%5Bp1%5D=321&deeperObject%5B0%5D%5Bdata%5D%5B0%5D%5Bp2%5D=123&deeperObject%5B0%5D%5Bdata%5D%5B1%5D%5Bp1%5D=121&deeperObject%5B0%5D%5Bdata%5D%5B1%5D%5Bp2%5D=423&deeperObject%5B0%5D%5Bdata%5D%5B2%5D%5Bp1%5D=221&deeperObject%5B0%5D%5Bdata%5D%5B2%5D%5Bp2%5D=133&deeperObject%5B1%5D%5Bprop1%5D=blabla&deeperObject%5B1%5D%5Bprop2%5D=false&deeperObject%5B1%5D%5Bdata%5D%5B0%5D%5Bp1%5D=222&deeperObject%5B1%5D%5Bdata%5D%5B0%5D%5Bp2%5D=443&deeperObject%5B1%5D%5Bdata%5D%5B1%5D%5Bp1%5D=321&deeperObject%5B1%5D%5Bdata%5D%5B1%5D%5Bp2%5D=213&deeperObject%5B1%5D%5Bdata%5D%5B2%5D%5Bp1%5D=111&deeperObject%5B1%5D%5Bdata%5D%5B2%5D%5Bp2%5D=421

Any recommendations how to best implement?  If you recommend using urlencoding for simple forms, but some other approach for more complex data, what criteria do you use to transition from one approach to another?

Thanks

[requinix]

#1 is a chore. #3 isn't a good idea either.

#4 is reasonable if you don't mind such long arrays and/or don't want to have to decode the form data yourself. Otherwise #2 is kinda the industry-standard approach.

[NotionCommotion]

Thanks requinix,

Yes, #1 is a chore!  What makes #3 a poor choice?

#2 in the industry standard approach?  For all requests or just those that contain complex data?  I expect it is totally reasonable to use url encoded data on a web app which just has simple forms, yes?   Do you feel it is important to be consistent within a given web app which has both simple forms as well as complex data requirements, and use #2 for both?

[requinix]

#3 mixes formats. You've got some part that's x-www-form-urlencoded and another part that's JSON. Both formats on their own are capable of representing the data in its entirety so there's really no reason to hybridize them together like that. It's added complexity for no gain.

#2 is standardized in that (1) sending the data as a complete thing is typical and (2) using JSON as the representation is more popular than the predecessor, XML. If you look at various non-trivial REST APIs around, particularly ones that make use of PUT, you'll see that most will encode the object as JSON and submit it. As an implementation detail with browsers, there's more support for encoding data using JSON than x-www-form-urlencoded, and most HTTP request APIs ultimately include a "set this string as the request body" step - and setting that using JSON is easy.

Is consistency important? Very. It means an implementer doesn't have to include logic about when to encode what data in which format - everything gets treated the same way. Imagine if road signs looked different depending if you were in a business or residential area. Or if you had to use one set of currency for buying food and another for buying household goods.

[NotionCommotion]

Thanks again requinix,  I suspected that #3 was undesired for unconsciously the reasons you described, but appreciate you making in concrete.

Yes, I agree consistency is important.  I also question ever tutorial or book I've ever read regarding how PHP should receive data from a browser client.  They all (as far as I know) recommend submitting a form using url encoded data and receiving the data in the super post array.  If I were to start over, I would consistently use json for all client to server requests just so I can use my existing code and not worry about forgetting how I did so for a given project (or worse for a given part of a project).  Am I wrong for thing thus?

[NotionCommotion]

PS.  What does url encoded data and whether xml or json have in common?

[ajoo]

Hi !

What you guys are saying is that it is possible to submit form data to a server using a method other than GET OR POST submit.

Would you please confirm if you are referring to submitting the form data using JSON format via an AJAX request using JS or JQ OR is this something else ?

Thanks.

[NotionCommotion]

Hi ajoo,  Yes, you can submit data from a form using methods GET and POST as well as DELETE, PUT, and maybe OPTION (I don't really know much about OPTION).

I think jQuery automatically detects the type and sends the applicable headers.

[requinix]

16 hours ago, NotionCommotion said:

I also question ever tutorial or book I've ever read regarding how PHP should receive data from a browser client.  They all (as far as I know) recommend submitting a form using url encoded data and receiving the data in the super post array.

Because that's the normal method supported by HTML. But when you start talking about APIs and REST it's time to use another approach.

16 hours ago, NotionCommotion said:

  If I were to start over, I would consistently use json for all client to server requests just so I can use my existing code and not worry about forgetting how I did so for a given project (or worse for a given part of a project).  Am I wrong for thing thus?

No, it's a good serialization format with good support.

16 hours ago, NotionCommotion said:

What does url encoded data and whether xml or json have in common?

They don't really have anything in common with each other.

5 hours ago, NotionCommotion said:

and maybe OPTION (I don't really know much about OPTION)

OPTION is a special verb not used for regular requests. The standard verbs are GET, POST, PUT, and DELETE, and there are some others like with WebDAV, and it's even possible to use custom verbs (but don't do that).

[NotionCommotion]

Thanks, makes sense.  Kind of.  Standard web sites use  use application/x-www-form-urlencoded and API's and REST use JSON.  But every web site I do uses an API (Slim).  I typically provide HTML for the main pages, and JSON for any of the Ajax requests, but even the main pages are rest api endpoints.  When you say another approach should be used be used for APIs and REST, are you referring to server to server or browser to server?

For browser to server, assuming application/x-www-form-urlencoded is the way to go, I was going to ask you how you would recommend dealing with an occasional one off where complex data needed to be sent from client to server, but I think I know it is my #4 option (url encoding the object resulting in a long string).

Also, for machine to machine APIs where JSON is the best choice, it is my assumption that I can use multipart/form-data and use json encoding for the data part.  Agree?  The use case is browser client uploads a file(s) and data to webserver using multipart/form-data with urlencoding and the webserver forwards the data and files to another server using multipart/form-data and json.  Do you know if guzzle has this capability (started using it for the first time today and so far like it).

Thanks

[requinix]

2 minutes ago, NotionCommotion said:

When you say another approach should be used be used for APIs and REST, are you referring to server to server or browser to server?

Depends what you mean by "browser to server". There's no reason why a website cannot use its own API. In fact many sites do. Like this one, though it's a bit more private of an API than something you'd find documented for anyone to use.

If you have a regular form then you should use it like a regular form because that's how they work. Anything else is up to you.

[NotionCommotion]

26 minutes ago, requinix said:

Depends what you mean by "browser to server". There's no reason why a website cannot use its own API. In fact many sites do. Like this one, though it's a bit more private of an API than something you'd find documented for anyone to use.

Yes, like this one.  Based on our discussions, I assume it uses urlencoding.

26 minutes ago, requinix said:

If you have a regular form then you should use it like a regular form because that's how they work. Anything else is up to you.

Most pages have regular forms.  But then I have a few others that use some crazy javascript to built some big complex object which needs to be included with other data from a regular form.

[requinix]

5 hours ago, NotionCommotion said:

Yes, like this one.  Based on our discussions, I assume it uses urlencoding.

Not necessarily. Applications that try to support non-AJAX situations are more likely to as they might simply intercept the form submission event and send it through AJAX instead, but it's definitely reasonable for a browser-based AJAX call to send data using JSON.

5 hours ago, NotionCommotion said:

Most pages have regular forms.  But then I have a few others that use some crazy javascript to built some big complex object which needs to be included with other data from a regular form.

Sounds like a job for JSON.

[NotionCommotion]

3 hours ago, requinix said:

Sounds like a job for JSON.

And all the other pages with urlencoding?  If so, then no consistency.  If not, then one should never use urlencoding in the first place.

[requinix]

URL encoding for <form>s that submit naturally. If you can coerce your data structure into hidden <input>s then great. But if not then use AJAX and JSON.

Or don't.