Tag Info

Hot answers tagged

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.


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

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

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

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

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

JSON is a data interchange/serialization format. It's not code intended to be written by humans, but human-readability is important. Given these requirements, JSON is the simplest subset of JavaScript that could possibly work. For example, we need to allow quoted keys in objects. But if we already have a quoted syntax, there is no need to support unquoted ...


4

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


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

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

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

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


2

I see two distinct subjects in your question: How to manage circular references when serializing to JSON? How safe is it to use EF entities as model entities in you views? Concerning circular references I'm sorry to say that there is no simple solution. First because JSON cannot be used to represent circular references, the following code: var aParent = ...


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

The server you are making the call to will call your function when it's done. That way you don't have to parse the immediate response (which may not contain the JSON). Say the server takes 10 seconds to do a long operation. Instead of leaving your connection open for 10 seconds it will respond immediately that it got your request. It will then start the ...


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

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

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

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


2

That should depend on what it is actually doing. If it is retrieving one or more objects, it makes logical sense to always return an array containing the results, even if it is an array with only one element. This makes it easy to then do a foreach on the returned array, for example. If the format of the request causes it to return completely different ...


2

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!


2

Plain JSON isn't RESTful since it lacks the hypermedia constraint. If you are making a small-scale web application and don't need the development overhead of REST, however, then plain JSON will work just fine. The Internet hasn't settled on a favored JSON hypermedia format. There are multiple formats available, each with their own pros and cons, and you ...



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