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


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


6

There is no theoretical limit to how deep JSON objects can be nested, but there usually is a practical limit based on the decoder being used. For example, PHP's json_decode() has a default limit of 512 levels, though it can be adjusted. Read the documentation for the code using the JSON to determine the max depth. If your JSON is actually hitting depth ...


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


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


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


4

I think you are starting from the wrong end. API design is about what the client/requester requires not about how you represent the data internally. If the client need the category name then just provide it along with the id (if its useful to the client). As a Post belongs to only one category there is no reason to have anything other than a flat structure. ...


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

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

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

While Jonathan largely talks about the nature of XSLT as a language in his answer, I think there's another angle to consider. The purpose of XSLT was to transform XML documents into some other document (XML, HTML, SGML, PDF, etc). In this way, XSLT is frequently used, effectively, as a template language. There is a vast array of template libraries out ...


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


3

Structurally, I would reconsider the notion that a post belongs to a category. That's a strange way to model the relationship, especially considering a post very well may form a relationship with multiple categories. So in my mind a post has multiple categories. As @James Anderson initiated, you shouldn't think about your API as a result of your persistence ...


3

404 is perfectly fine for this use case. 4xx status codes are client error codes, so browser treats them as such, and that is perfectly fine too. Another kind of APIs (e.g. JSON-RPC) use different approaches, but since you're going RESTful, do not change response code just to make console output look pretty - it is not a use case, users are not supposed to ...


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

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

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

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


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

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



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