Tag Info

Hot answers tagged

41

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.


12

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


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

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


10

Suppose I have a server-side variable containing JSON, called strJSON that my own code created. Was it created entirely by your code? Are you certain that at no point does it add in a piece of user input? Are you also certain that at no point in the future will it ever be modified to add in data that comes from user input? If you can be 100% sure of ...


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

Coming from a front-end developer perspective, I prefer simple and semantic as much as possible. Generally inside a consistent envelope for debugging and tracking, the actual data would be as follows: { "images" : [ { "id" : 123, "filename" : "someFile.jpg", "caption" : "some image or other", "gallery" : ...


5

JSON representation can be dense, certainly denser than a flat list of properties, so memory exhaustion and denial of service may be slightly easier. Other than that, assuming your JSON parser is bulletproof, you're left with basically the same attacks that can be directed at a form-data or query-string based entry point, primarily various kinds of string ...


5

I think your question really boils down to: When should I use a NoSQL approach vs. RDBMS? You settled on JSON early (a NoSQL-ish decision), perhaps because you've got Ajax consumers. The answer of course to when to use NoSQL approaches vs. RDBMS's is basically about what type of data you're working with and what consumers you anticipate having. If your ...


5

Use a mvw (model/view/whatever) pattern model: "pure" javascript library modelling abstract concepts. This part usually contains objects & methods names related to the application domain (car business -> car objects / insurance contracts) and the data access logic. view: a custom language describing how your UI look like. Preferably, the language ...


5

You are assuming JSON is always better than HTML, which is controversial at best (see MainMa's answer). But let's assume you're right. Why don't we get rid of HTML? The surface answer is compatibility, but why is compatibility even an issue? The fundamental reason you can't make these kinds of changes on the web is because the web is a decentralized system ...


4

For scalability reasons I would like to keep the server's load a small as possible I think this is more or less pointing to the answer. Whether or not providing preprocessed data to the client or not depends mainly on: the difference with regard to traffic the performance impact of the processing the impact of a different data format on the client ...


3

Although the right solution depends on your context, here is my approach: When designing classes one should always consider their single responsibility. In case of the PostsController it could probably be described "create, read update and delete" posts. Formatting of the output is a global problem of your application that should not be solved individually ...


3

Loading values from JSON is only useful if at some point something uses these values. Since you want to allow modders to use "arbitrary" structures(which I assume means "their own structures"), it's clear that it's not your own code that will use the data from that JSON - it'll be the modders code. Now, there are two ways for letting modders add their code ...


3

Svn basically stores the diffs between subsequent versions, so breaking the lines as to minimize the size of the diff should minimize the amount of storage you use. Git compresses its revisions somewhat differently, so breaking the lines may not matter as much. Whether it's significant in practice you can only tell by measuring. My recommendation is to ...


3

Don't do it! There are so many options these days for actual databases in every context that one should almost never use something else as if it were a database. For small and simple projects, you can at least use SQLite - it's probably used by several apps on your phone!


3

While JSON has a benefit in terms of size (and so bandwidth) and simplicity (slightly easier to parse for smartphones), such major change of replacing one language by another would be too disruptive to justify the minor gains in bandwidth and performance. Such gains were maybe relevant ten years ago where mobile devices were very limited in terms of CPU and ...


3

I use MVC in both. Yes the views server-side are very simple, but that's ok. Still nice to have separation of concerns for all the usual reasons.


3

Despite having the word language in them, I would not consider them programming languages, but rather data formats. I know that XML has been used as the format for some DSLs, probably likewise for YML. A language does not have to be Turing complete to be a programming language, but it does need to be active -- without exceeding the standard definition, ...


3

Welcome to the wonderful world of middleware development. It can be a lot of hard work and debate to develop a protocol, and no one should ever see the results. If you are on a small team, then avoid a dictator: have quick meetings with everyone to hammer out the protocol. Medium sized teams may wish to have representatives that work out the protocol. ...


3

It's usually a good idea to separate the serialization method (JSON) from your business logic so that if in the future you decide to use some other type of serialization, you can do so without affecting the business logic. Jackson is probably the most popular open-source library for JSON serialization/deserialization in Java. In the situation where some ...


3

If the JSON string is encoded entirely under your control, it is exploitable to the extent that your encoding method is broken. That said, you should be safe if you're performing a straightforward serialization using a trusted serializer, like so: var js = new JavaScriptSerializer(); var thingy123 = ThingyRepo.Get(123); var json = js.Serialize(thingy123); ...


2

You really should do only one of two things Either Return a 200 (OK) status code, and an empty array in the body. Or Return a 204 (NO CONTENT) status code and NO response body. To me, option 2 seems more technically correct and keeping in line with REST and HTTP principles. However, option 1 seems more efficient for the client - because the client does ...


2

Mainstream Javascript engines added JIT (Just In Time) compiling around that time. Mozilla added TraceMonkey to Firefox, Google added Crankshaft to v8 around that time as well. John Resig mentioned TraceMonkey when it was just coming out. These optimizing runtimes improved javascript performance in browsers by an order of magnitude. Before then, ...


2

I believe there are more considerations here that you may not be looking for. There are two broad concerns here: Storage Search and Retrieval Storage There are plenty of opinions on why to use no-sql or RDBMS store for your data. One of the most important items that we thought was useful is that we can easily define and store json objects in storage ...


2

Sounds perfectly reasonable to me to add the store ID into the payload - as you say, the payload is then more "standalone", and should not need modified after being parsed. Messing with the object to inject a field that you could trivially include when building the response feels wrong to me.


2

Depending on which browsers you need to support, you may be able to take advantage of the HTML 5 template tag. The template tag allows you to keep your partial HTML elements in the HTML file but not have them rendered in the browser. In order to actually display the contents, you clone the template's contents and add it to the DOM using javascript. You can ...


2

The real answer ("tell between invalid JSON and a string") For a lot of obvious reasons we're not going to come up with a definite answer - we can at best hope to determine an index that will tell us whether a string might have been JSON. The best approach I can think of is to use something like the Levenshtein algorithm, with this twist: we have no "B ...


2

There is a third option which you may not have seen: Cross Origin Resource Sharing (CORS). The CORS standard works by adding new HTTP headers which allow servers to serve resources to permitted origin domains. Browsers support these headers and respect the restrictions they establish. Example: Say your site is http://my-cool-site.com and, you have a ...



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