Hot answers tagged

8

Yes, this is definitely possible. Invertible syntax descriptions: Unifying parsing and pretty printing by Tillmann Rendel and Klaus Ostermann is one fairly well-known approach for parsing/unparsing (which is kind of what you are doing) based on partial isomorphisms. The paper also points to other approaches based on Arrows (Polytypic compact printing ...


6

XML and JSON are both capable of transmitting the same data, but which is better depends mostly on what you want to do with it. This does touch on existing tooling, but you're not likely to be hand rolling parsers for either, so it is relevant. XML Has better tooling for verifying schema. Has built in support for namespaces. Can be more easily ...


6

On languages such as Haskell, most datatypes have instances which allow their values to be used as keys of structures such as Maps. It's the same in ECMAScript. Any object, including primitives, can be used as the key in a Map. Even NaN, even though NaN !== NaN // true does the right thing and can be reasonably used as the key in a Map. JavaScript ...


5

In practice the second option is the best practice. Reason for this is that you cannot extend the resource at all when you just return an array. For example: If you need to add a count of all records you are already done with the array only approach. If that happens in one list api then you want to keep it consistent so make all an object then your api ...


5

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


5

Effectively, a flow chart is just a fancy graph. So, you will have nodes and edges. Nodes will have text, (optionally) position/size, and unique ids. Edges will have a pair of nodes and a name. So, suppose we have, "Ask user their name. If their name is Bob, compliment them. Otherwise, hang up on them." Something like this: var JsonGraph = { ...


5

A JSON API should return JSON. That's why it's called a JSON API. All the users of the API will be expecting JSON, because it's a JSON API. If a JSON API returns something other than JSON, then it is not a JSON API. If you're going to continue to call your JSON API a JSON API, and it returns something other than JSON, then indeed that is quite undesirable. ...


4

XML is an eXtensible Markup Language. That's important to understand: It's designed to be essentially like HTML--a document markup language--but a bit more formalized. Problem is, document markup isn't what anyone uses it for. People abuse it for data storage and data exchange, which is a really bad idea because data storage isn't anything like document ...


4

It's a bit of apples and Oranges. They are both used for the same task yes, but they are distinctively different. XML is Extensible Markup Language. The main benefit of it is that it can cary meta data. In short: <tag attribute="something">data</tag> So having attributes on your elements allows you to be more explicit. More on that you can ...


4

I'm no expert on JS or PHP so there might be some caveats I'm not aware of, but these are some ideas that come to my mind when I see this. First off, I think your first idea is great. To answer the points you are raising: Is it okay to use the property "name" twice, since they are on different levels? I've read that it's better to keep the property ...


3

If the user 52 doesn't exist, return HTTP 404. Returning HTTP 200 is misleading. Think about it from the point of view of the client. Would the following dialog make sense to you? Client: please, I want to know something about user 52. Server: of course (HTTP 200). What do you want to know? Client: I want to know the basic information about the ...


3

You should probably go for option 1, but made more RESTful. It may also make sense to provide something like option 3/4. There's nothing forcing you to pick only one. However, what you should do is replace ids with links. Instead of having a "sender_id", you should just have a URI pointing at that user resource. Notice how this means I don't need to ...


3

What you really want is a Map, not an object: Map You need to check if the support you need to provide fits with the Map supported browsers, but that´s what you really want as objects only take strings or symbols as keys while a map can take anything Here is an example of its usage: var point1 = {"x": 7, "y": 8, "z": 9}; var point2 = {"x": 6, "y": 5, ...


2

Here are a few examples of what you can do with my (small[jslt.min.js]) JSLT -- JavaScript Lightweight Transforms: https://jsfiddle.net/YSharpLanguage/c7usrpsL/10 ([jslt.min.js] weighs ~ 3.1kb minified) that is, just one function, function Per ( subject ) { ... } ... which actually mimics XSLT (1.0)'s processing model. (cf. the "transform" and ...


2

I was able to resolve the "$ref" links in my json code by adapting the code, this blogger posted, to be Angular compliant. http://willseitz-code.blogspot.com/2013/01/javascript-to-deserialize-json-that.html I created an angular service to resolve the "$ref" I get from NewtonSofts JSON serializer. // ...


2

This topic may already be closed but for the sake of dicussion, I will put my 10 cents thought in here. I'm doing a research at json and Web Service security and I think you should always return a json object instead of json array. The reason for this is that json array can be tampered with to return some XSS script. For example: if the array return is [1, ...


2

A dictionary with a single meaningless key "list" and an array value is pointless - return an array instead. If the same service could return books, CDs or DVDs, then you could return a dictionary with a key "books" and an array value. There could be another key "DVDs" with an array of DVDs. For example if a customer can enquire a list of all their ...


2

Both [{"author": "Dan Brown", "isbn": "123456", "title": "Digital Fortress"},{"author": "JK Rowling", "isbn": "234567", "title": "Harry Potter and the Chamber of Secrets"}] and { "list": [{"author": "Dan Brown", "isbn": "123456", "title": "Digital Fortress"}, {"author": "JK Rowling", "isbn": "234567", "title": "Harry Potter and the Chamber ...


2

If you want to go with the file approach and have mostly static and configuration data use SQLite (PHP entry): it is a RDBMS just like MySQL, but it is a local single file in a directory of your choice (it can even be in your application's folder), installation free, lightweight and can accomplish your data requirements with consistency and a lot of tested ...


2

If I'm understanding you correctly, you are providing a list of items with 2 (or more) categories and you want to display them sorted or separated in some way. The options are multiple requests, one for each selected category. Or a single request allowing the client to specify multiple categories. If that's in any way close to the correct understanding, ...


2

A lot depends on how much traffic you expect to see and how often this situation will occur. To avoid premature optimization, I'd first go with a variation of your 2nd choice - treat the duplicate request as an error (and log it as such). If you see it happening often enough to warrant action, then your 1st choice - cache the output - seems reasonable. ...


2

This is a tough question to answer definitively, because this space is still relatively young. When it all settles down, then we will know what the answer should have been. :) Since the kinds of objects and their specific properties are potentially unbounded (depends on what comes to market), I would be tempted to treat each node as essentially a data ...


2

Well if you embed a unique identifier for each request, then you can respond with a more structured class and still give the client a way to know which query failed. public class TestResponse { private final List<QueryResponse> responses; private final List<QueryError> errors; // .. constructors and getters here } public class ...


2

If you value consistency then the service that stores the data should be the definitive 'master' source of what the data looks like. This means that the front end must defer to whatever the service says. Now that doesn't mean it cannot cache results, but it should not make assumptions about logic that may (or may not) be processed on the service. eg. Lets ...


2

What I am missing here ? "s". You need to be using https, which is end-to-end encrypted, not "raw" http.


2

Let's just say in a year from now you decide that you need support em or whatever other type for width. For compatibility I would go for the first alternative as I think this change might be difficult with one of the other two. Another solution might be to define types: { "width": 50, //Always a number "type": "absolute" //Possible values: "px", ...


2

You can do better than either XML or JSON by exploiting the particular characteristics of your particular data. If the data is completely flat and every row contains the same fields, then CSV is going to be more efficient than either XML or JSON. The reason people generally prefer formats like XML and JSON is because they recognise that the life-time cost of ...


2

It's certainly being done, but I think whether it's a good idea depends on the style and size of application. How big is this application and how long will it live? It's harder to trace behavior and refactor with a very long path of code that might rely on the object-properties and relationships, meaning it has to be inspected and fixed as a unit. (As ...


2

I think two issues to consider are: (and you're referenced this above) - do you need to find child nodes ? In which case you perhaps want to avoid storing sizeable hierarchies and instead store the individual Foos such that they're immediately searchable. That may impact tree construction/retrieval times Do you want to move children between trees? If you ...


1

A drag/drop UI typically encourages users to play around with the interface. You may not want to have every UI operation send data back to the server every time they interact with the interface. Depending on the specific interface it may not be an issue, but it's something to think about. What happens to the UI if the server response time starts to grow? How ...



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