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


7

You can use anything as JSON keys, as long as it is valid UTF-8, doesn't contain zero code points, and it would be useful if you could represent the key as a string in the programming language of your choice. I might recommend not to use different Unicode representations of the same string (for example "Ä" written as one or two code points). Reading some ...


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


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 = { Root:...


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

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.


5

Whether you choose the first or the third option depends on your use case. If you are modeling many different instances of the same type of thing, choose the first. For example, you have a list of people. If you are modeling many different attributes of one thing, choose the third. You can have repeated keys in the first format, but not in the third. ...


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


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

There are plenty of JSON serialization systems that are more than capable of handling mapping between field names that aren't suitable for use in the language they integrate with. In most cases, they aren't hard to use, and require only a little bit of extra effort. In an ideal world, you wouldn't have to, but if your API already uses dashes, changing it ...


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


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


3

GET /api/sprinkler that returns 200 and {"status": "on"/"off"/"damaged"/"no water".....} In my view assigning meaning to error codes which already have a defined meaning is a bad idea. How would you distinguish between "off" sprinklers and "client pointing at the wrong url" exceptions?


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

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. // http://willseitz-code.blogspot.com/2013/01/javascript-to-...


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

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

Since you're using jackson you should take a look at this : https://github.com/FasterXML/jackson-datatype-hibernate With this module, jackson will not serialize LAZY fields if you didn't initialize them, so you could have LAZY fields on both sides to not have any problems. If this solution does not suit to your needs (maybe you want some eager). Then ...


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

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

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

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

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

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


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



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