Tag Info

Hot answers tagged

124

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 ...


83

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 ...


35

This is a conversation you should be having together, discussing the requirements and pros and cons of different formats. If one side or the other is dictating what happens, you're going to end up with bad software and an unhappy team.


31

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.


28

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.


16

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", ...


16

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 ...


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, ...


13

JSON is just a data-interchange format based on JavaScript. REST is an architecture style whereas OData is a specific implemenation of REST designed to generate and consume data, which supports two formats, AtomPub and JSON. So the difference between JSON with plain REST and OData are the options in OData for data manipulation eg, if we query data using ...


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, ...


11

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.


11

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: [ ...


11

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

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

The proxy option is the easiest one to implement. You don't have any custom development to do, the only thing to do is to set up a proxy. It's also straightforward: there is no additional code to maintain, and if the API changes, you have no changes to make on your side. A proxy would be a preferred choice: If you need to ship working software fast. This ...


10

XML : XSLT :: JSON : x. What is x ? The most facile answer would be x = JavaScript. Though you could make a case for this, it feels unsatisfying. Even though XSLT is technically Turing complete, there is a poor correspondence between the declarative style of XSLT and the more imperative or functional styles seen in JavaScript. There are a few standalone ...


9

XML = "eXstensible Markup Language" YAML = "YAML Ain't Markup Language" (Though it was originally "Yet Another Markup Language".) Though in truth people think of them more like data formats (which JSON is) rather than languages partly because people assume "Language" == "Turing Complete".


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. ...


8

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: ... </></></></></></></> ...


8

You most definetly should contribute to how the format and structure of the JSON should look like. I see it more than often that the front-end engineers, the API consumers, is the ones knowing how the data-structure should be. You are the one going to use the data, format it, loop through it and work with it. You should have an opinion on how you want it ...


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

CouchDB. It's a document-oriented database server. Its network protocol is based on HTTP and JSON. It does exactly what you described. The biggest drawback: it lacks a lot of the features that people take for granted when using relational databases. This may or may not be a problem for you.


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 ...



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