Tag Info

Hot answers tagged

116

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


78

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


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

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


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


14

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


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

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

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


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

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

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


6

There has been a reasonable amount of work done on creating a standardised JSON API format. Following the principles in that specification mean that all resources returned should effectively be "collections" (even when just a single resource is included). Following this would mean that your call to /v1/get/movies would return: { "movies": [ ...


5

I'd say that cwallenpoole makes an excellent point. While most XML can be translated to JSON, whether doing so is better for it is a separate point. JSON lends itself to data structures at least as well as XML and probably better, but XML reads much more naturally than JSON when marking up textual documents, where tags are used within a larger flow of text ...


5

XML is used for more than just AJAX. For example, if you are doing any web services you will definitely encounter XML. Reading/writing configuration files? XML is often used there too. My advice, however, is to learn enough about it to know when it is a good fit for any projects you might come across, and then do a deep dive when you actually have some work ...


5

Yes, most languages have JSON bindings available. Check out JSON.org; there's a fairly extensive list if you scroll down a few pages. So you've basically got three problems here, and it's best to separate them into their own layers. You need an HTTP server. Just about any language has one. Looks like you'll want to put some specific logic about parsing ...


5

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.


5

For what you describe - it sounds like a blogging platform where everything is submitted via forms - no, you dont need to convert it all to JSON. PHP handles forms seamlessly for you. There's no reason to introduce a new piece of complication in that situation. Again, in your specific circumstance, JSON might be something you'd use if you needed to send ...



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