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.


13

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


6

From the comments... if everything else you have is C++ then the best answer is to write it in C++, building a mish-mash of different bits of programming languages is a right PitA to maintain and support. So, if you have C++ and need to resolve XML to JSON, it seems obvious to use the xml2json library that you linked to. It comes with sources so you can ...


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


4

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


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

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

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

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

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

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


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

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

The purpose of a JSON Web Token is to authenticate you, not to secure the payload. Securing the payload is a separate operation. Naturally, you can encrypt the payload if you wish, but that's not the purpose of a JSON Web Token. You don't encrypt the payload for the same reasons that you don't encrypt anything else: the cost (however small it is) exceeds ...


3

Consider removing empty or null values. If a property is optional or has an empty or null value, consider dropping the property from the JSON, unless there's a strong semantic reason for its existence. { "volume": 10, // Even though the "balance" property's value is zero, it should be left in, // since "0" signifies "even balance" (the value could ...


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

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

While you do not anticipate changing the nature of your objects now very much - needs change over time. I would highly suggest you consider using protobuf or Apache Thrift or a similar design instead of relying on default Java serialization. Their advantages include strong support for avoiding impact during minor version changes, significantly better ...


2

The biggest problem is the huge set of assumptions that you so easily skip. Just take your example: "$600 is paid by Client A for inspection" USD or other dollar? Paid when? To whom? What counts as an inspection? Is this a mandatory payment, or only incurred if A opts to do the inspection? Are multiple inspections allowed, If so, is this per inspection? ...



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