Tag Info

Hot answers tagged

118

The thing that gives XML its power and a lot of its complexity is mixed content. Stuff like this: <p>A <b>fine</b> mess we're in!</p> Don't even try to do that in JSON, or manipulate it in conventional programming languages. They weren't designed for the job. This kind of question usually comes from people who forget that that the ...


81

Your example is broken. You shouldn't have json objects with duplicate keys. What you are looking for is an array with movie objects, like this: [ {"name": "movie1"}, {"name": "movie2"} ] This approach also answers your question. You should return an empty array when the query does not match: [] On the other hand, if you try to get a ...


29

Usually I would return number of records in result as metadata. I am not sure if that is normal REST practice, but it is not much extra data, and it is very precise. Usually there is pagination for lots of services, it is impractical to return huge resultset at once. Personally I am annoyed when there is pagination for small result sets.. If it is empty, ...


28

JSON is notation for an object. Not an object itself. A "JSON Object" is a String in JSON notation. That's not redundant. Saying "JSON String" would be more clear than "JSON Object". But they would mean the same thing. "JSON Object" can be shorthand for "JSON-serialized Object". It's a common-enough elision of confusing words.


27

The main difference, I think, is in the fact that XML is designed to be self-explaining with its dtd's and everything. With JSON, you have to assume alot about the data you are receiving.


15

A literal translation to JSON is often less succinct and less clear. Consider: <foo> <x:bar x:prop1="g"> <quuz /> </bar> </foo> The most effective JSON representation I have seen of this: {"localName":"foo", "children": // you need to have a special array to hold all children [ {"localName": "bar", ...


15

JSON has a few advantages: It's a structured format, which can be validated and parsed with existing, mature tools. It can speak easily to JavaScript, which makes it very useful for AJAX communication. It's extremely simple and lightweight. Anything you'd want to use XML data interchange for, JSON is generally a better alternative. My rule of thumb is, ...


15

Size is not so much of an issue, the ability to query and maintain the data however is. If, for example, Greenhaven Press decides they want to change their name to Greenhaven Press International, you'll have to find the record, deserialize it, change it, serialize it, pump it back into the database. Consider this: does storing these objects as serialized ...


12

XML really is a pretty horrible way to represent structured data, but unfortunately it gets (ab)used quite a lot by a lot of developers and websites. So if you're only working with your own stuff, then by all means, stick to JSON and save yourself the hassle. But you still need to learn XML for those times when you end up having to interoperate with ...


12

JSON and XML are both ways of formatting data. Both are capable of doing it perfectly well, so can JSON do everything XML does? Yes. But..... A more relevant question might not be what XML/JSON can do, but rather, what can you do with XML/JSON. There are several things you can do with XML that I don't think you can with JSON, such as translate with XLST, ...


12

If you execute operation successfully, but it doesn't have anything to return, such as empty map {} or empty array [] I would prefer to respond with 204 response code, here is excerpt from HTTP Status Code Definitions spec: The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. ...


11

Can we change XML format (i.e. create a new language which doesn't have the verbosity issue)? Yes, we can. In order to completely migrate to the "better XML" (let's call it BETXML), it would require to: Reimplement all the parsers, Rewrite all applications which currently use XML, Rewrite all protocols based on XML. Or we can keep everything in place, ...


11

Because you can do many more things with real data besides display it in a web page. HTML is just a type of output that web browsers recognize, and it's not really useable as data in a meaningful way, because its metadata is about structure and form, not about the data itself. It also contains all sorts of things that have nothing to do with data output, ...


10

There's a lot of functionality using XSLT that may not be possible with JSON. So, if they're not functionally equivalent they couldn't replace each other.


10

The decision of whether to use relational DB or non-relational (document/OO/graph) database should not be based on the representation of the data (JSON/BSON/XML/...), but on the operations you intend to preform on the data. If you have a strict schema, and you need to execute SQL queries - You should use relational DB. Otherwise, you may consider other ...


10

If this is JSON, you should really consider returning an Array of objects. This has many advantages including that when you have no records it is an empty array. So when you have records, you would be returning: [ {"name": "Ghostbusters"}, {"name": "Indiana Jones"} ] And when you have no records, you would be returning: [ ...


8

JSON should just contain the data and no markup. In the long run this approach is more extensible because there is potential for using the JSON data in other parts of your site. If you include markup then using the same data to populate another template becomes much harder.


8

I've been working with a similar pattern over the past several months. My personal opinion is that it is ok to mix these two conventions depending on the needs of the plugin. If you have a small number (i.e. < 5) of well defined parameters or if you want to select elements based on a particular attribute then data attributes for each parameter is ok. ...


7

JSON is fairly new and legacy systems wont support it. Upgrading legacy systems is expesive and introduces bugs. JSON wont replace XML any time in the near future.


7

Why not just use javascript? (JSON is Javascript Object Notation after all). You then won't have to parse or manipulate the JSON. EDIT Have a look at http://json.org/java For this requirement converting the whole JSON message to object sounds bit expensive to me and hence this question. It isn't. Deserializing an object is cheap (bench test it ...


7

JSON logging gives you the ability to parse the log file programmatically even if the format has changed in time. A good example is Apache logs. By default Apache uses common format for access.log: "%h %l %u %t \"%r\" %>s %b" Say that you have built an offline parser that takes one of those log files and calculates some statistics from it. At some ...


7

After looking at your requirements, and seeing that you have a dislike for XML, I would advise you to go with JSON. I must admit that I've only dealt with XML and JSON, so I cannot speak for any other common configuration formats out there. JSON is really easy to write, and if formatted correctly, easy to read. Google just LOVES JSON for configuration use ...


7

I would go with 2. create a table Sub-pages which references it's parent section by a Foreign Key When you have to do such Sections Sub-pages like things then I would go with creating separate tables so that it becomes more efficient in organizing the data. There's one scenario that I know which I would like to tell you. If you store all the ...


7

I fail to see the big gain with the </> variant. Are you talking about readability for the human eye? In that case I would take ordinary XML any day rather than trying to figure out what the code is trying to tell me when I see something like this in the middle of a file: ... </></></></></></></> ...


7

There are really two definitions of REST: Representational State Transfer ("REST") as a principle for service design (not necessarily web service!), which suggests a uniform client-server interface where the server does not store the client context, e.g. "client has visited this page last". As a general principle, RESTful services shuold request a ...


7

Note that the license refers to the reference implementation of JSON, not to the JSON format itself. As an aside, I find it amusing that people get so worked up over the "not evil" clause. See this Douglas Crockford video for some perspective.


6

Both are important and relatively trivial to pick up. At the end of the day, you should know both as a web developer so you can choose the best solution for the specific problem at hand.


6

Ajax/JSON/XHP/XHR/$insert_stupid_neologism_here is as safe as vanilla HTTP (because it is vanilla HTTP) if and only if the site is secured with SSL and you use a token system to prevent cross site request forgeries.


6

There is not a YES or NO answer to your question. The decision to introduce a second level of indirection in the form of an xml/json API depends on what you are about to do with your project. As you mentioned, many projects go mobile these days, however, isn't there a simpler way to provide mobile functionality by simply presenting a customized version of ...


6

I think YAML is best fit for your case. To my understanding, YAML is the de facto standard format for configuration files that need to be edited by hand. Many programming languages have a library for reading and/or writing YAML. JSON is closely related to YAML, but is little bit less easier to write than YAML, and is used more for communication between web ...



Only top voted, non community-wiki answers of a minimum length are eligible