21

It's hard to decide,
currently I'm sending data as x-www-form-urlencoded with php lib curl with

curl_setopt($curl, CURLOPT_POSTFIELDS, http_build_query($this->arguments));

or

curl_setopt($curl, CURLOPT_POSTFIELDS, $this->arguments);

first question: second one seems to be larger content length, first solution is probably better?

It's practical for flat messages like:

{
    "name": "John",
    "token": "2121232145",
    "code": "7",
    "data": "Hello"
}

But I can have also a data field that represent a object, in this case I was enconding it, but doing that (url encoding a Json) is terribly verbose and ugly messages,

On the other side I tried sending it as application/json content-type

curl_setopt($curl, CURLOPT_POSTFIELDS, json_encode($this->arguments));

the content-length is larger for small messages but with embedded json, it's clearly better

But x-www-form-urlencoded is also close to the forms data I need to send, except when a json is embedded

It would not be elegant to have 2 differents servlet parse methods depending on the content types, so is there another option?

  • 1
    SHORT: x-www-form-urlencoded. LONG: it really depends what kind of data do you send (complicated nested objects or just few fields like in example). Also it depends what are you going to do with sent data, will it be immediately parsed and processed or it will be stored and then send to user as is (in json encoded format)? – pinepain Nov 19 '12 at 12:50
  • @pinepain the data is sent to a glassfish server, is parsed and inserted in a Cassandra database, it can be fairly nested like this `{'data': json_encode({'text':'2klines..', 'author':'me'}), 'id':'14141','keywords':json_encode({[{'tag':['blue','red']},{'author':['me']}}), ..}` –  Nov 19 '12 at 14:24
  • Using the same way to do things simplifies a lot. Why not use JSON everywhere? Because of PHP which treats form data as $_POST/$_GET/$_REQUEST variables and JSON data with boring file_get_contents('php://input'). I dislike that the world spins around PHP. In Node.js it is pretty simple and natural to use JSON instead of form data. – Brian Cannard Apr 28 '16 at 10:21
  • Possible duplicate of [differences in application/json and application/x-www-form-urlencoded](http://stackoverflow.com/questions/9870523/differences-in-application-json-and-application-x-www-form-urlencoded) – einverne Jan 19 '17 at 08:25

2 Answers2

22

Here you can read similar discussion about formats.

If the structure of encoded data is guaranteed to be a flat list of name-value pairs, x-www-form-urlencoded seems sufficient. If the structure could be (arbitrarily) complex (e.g. nesting lists or associative arrays), then definitely use JSON.

As for me, I'm the KISS adept. In your situation JSON/XML/whatever is extra costs in time, memory and CPU cycles. x-www-form-urlencoded data combine readability and compactness so i can bet it's your choice.

pinepain
  • 12,453
  • 3
  • 60
  • 65
12

x-www-form-urlencoded and JSON are different things. While x-www-form-urlencoded is simply default content type which used to submit the form to the server, JSON is text-based and human-readable format (standard) which used for serializing and sending structured data over a network connection. You should not compare them.

second one seems to be larger content length, first solution is probably better?

No, there is no solution labeled as "better". Like pinepain's said, it really depends what kind of data do you send and how to parse / process it. JSON perfectly fits to send additional data with request.

Don't think about the content-length. Think about the data and data structure which you want to send and process it. If you just want to send and process structured data between requests and data-size varies, simply use JSON. It's built for this.

Content-Length difference between two methods wouldn't part of problem since your app is not a Facebook, Twitter or Google like monster. Premature optimisation is root of all evil.

Yuri
  • 4,254
  • 1
  • 29
  • 46
edigu
  • 9,878
  • 5
  • 57
  • 80
  • 14
    All I'm reading here is: "Premature optimisation is root of all evil. Go with JSON." This is not helpful. OP is clearly asking about the differences between the two solutions. Besides, who knows if this is premature? OP might have been at the end of the project looking for easy-to-realize to optimization options. – Jozua Sep 26 '14 at 14:24