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.


14

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

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


7

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


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

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

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

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


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

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

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


3

The reason you make your response JSON compliant is that JSON is a defacto standard; any language with a JSON parser can trivially parse it, and if you're using JavaScript, you don't even need a parser since JavaScript understands it natively. In other words, make it JSON compliant, and you won't have to write your own parser. Further, there will be no ...


2

HATEOAS is a somewhat controversial topic. Many people feel it's an example of overengineering and see no practical benefit to it. I believe it offers a natural and sensible approach to implementing Web APIs, with the benefits of increased decoupling between server and clients and a lower burden on client developers (see my answer to "REST HATEOAS - How does ...


2

Declarative Languages Declarative programming is often defined as any style of programming that is not imperative. A number of other common definitions exist that attempt to give the term a definition other than simply contrasting it with imperative programming. For example: A program that describes what computation should be performed and ...


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


2

At the syntax level, either XML or JSON would do fine. But that's the easy bit. The challenge is defining what can go in the rules. I would adopt a standard object modelling approach: what are the entities you need to represent, and what are their attributes and relationships? When you know that, encoding it in XML is easy.


2

The most commonly accepted way is to use a Business Rules Engine of some sort. Of course, if you're willing to roll your own BRE, and just need a reading on the markup language to use, I would imagine that XML is as good as any. It is hierarchical, has namespaces, and is unlikely to become obsolete any time soon. Since it's likely that we're not talking ...


2

I think the standard you are looking for is JSON Schema. It's not specific to forms, it's a more general specification for defining what a particular JSON format looks like (like an XML schema). There are a few solutions for creating forms with JSON Schema, like joshfire/jsonform.


2

Nothing is wrong with this for development. If it has a name, I suppose it would be a mock database. It is not uncommon to create a mock database that can emulate very basic functionality. You have the added advantage that you start from a scratch database each and everytime, thus you know that your program would work also for a potential empty nosql ...



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