Hot answers tagged

105

Your example is broken. You shouldn't have json objects with duplicate keys. What you are looking for is an array with movie objects, like this: [ {"name": "movie1"}, {"name": "movie2"} ] This approach also answers your question. You should return an empty array when the query does not match: [] On the other hand, if you try to get a specific ...


93

Using a scripting language in place of a config file looks great at first glance: you have the full power of that language available and can simply eval() or import it. In practice, there are a few gotchas: it is a programming language, which needs to be learnt. To edit the config, you need to know this language sufficiently well. Configuration files ...


51

+1 to everything in amon's answer. I'd like to add this: You'll regret using Python code as your configuration language the first time you want to import the same configuration from within code written in a different language. For example if code that's part of your project and it written in C++ or Ruby or something else needs to pull in the configuration, ...


46

Usually I would return number of records in result as metadata. I am not sure if that is normal REST practice, but it is not much extra data, and it is very precise. Usually there is pagination for lots of services, it is impractical to return huge resultset at once. Personally I am annoyed when there is pagination for small result sets.. If it is empty, ...


45

I think your question really boils down to: When should I use a NoSQL approach vs. RDBMS? You settled on JSON early (a NoSQL-ish decision), perhaps because you've got Ajax consumers. The answer of course to when to use NoSQL approaches vs. RDBMS's is basically about what type of data you're working with and what consumers you anticipate having. If your ...


42

JSON is just a data-interchange format based on JavaScript. REST is an architecture style whereas OData is a specific implemenation of REST designed to generate and consume data, which supports two formats, AtomPub and JSON. So the difference between JSON with plain REST and OData are the options in OData for data manipulation eg, if we query data using ...


42

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.


36

JSON logging gives you the ability to parse the log file programmatically even if the format has changed in time. A good example is Apache logs. By default Apache uses common format for access.log: "%h %l %u %t \"%r\" %>s %b" Say that you have built an offline parser that takes one of those log files and calculates some statistics from it. At some ...


35

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


31

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


30

Size is not so much of an issue, the ability to query and maintain the data however is. If, for example, Greenhaven Press decides they want to change their name to Greenhaven Press International, you'll have to find the record, deserialize it, change it, serialize it, pump it back into the database. Consider this: does storing these objects as serialized ...


28

When you are sending an accept header requesting a specific media type, the server should not send back something else, and most certainly not with a 200 OK status code From Restpatterns.org: If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field is present, and if the server cannot ...


28

You choose not to encrypt the payload for the same reasons that you choose not to encrypt anything else: the cost (however small it is) exceeds the benefit, and a lot of data simply doesn't need to be secured that way. What you mostly need protection against is people tampering with the data so that the wrong record gets updated, or someone's checking ...


27

If your machine runs so close to its limits that such issues really would matter, you most likely have more serious problems. While there may be exceptional situations where this makes some difference, many applications (maybe most) run on machines for which the difference if you log JSON, simple text or records to a database doesn't matter at all. Objects, ...


27

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


23

Yes there is a downside: bugs in your half baked parser. Sure JSON is simple but you still can encounter tricky escaping situations. Just use an existing tried and true JSON parsing method and save your brain cells for the harder problems.


21

The other answers are already very good, I'll just bring my experience of real-world usage in a few projects. Pros They are mostly already spelled out: if you are in a Python program, parsing is a breeze (eval); it works automatically even for more complex data types (in our program, we have geometric points and transformations, which are dumped/loaded ...


19

The most direct quote I've found is part of Scott Guthrie's announcement of the MVC 4 roadmap, back in 2012, (apparently offline but available via the Wayback Machine) which contains the following quote: Json.NET: We plan to use the community developed Json.NET serialization stack in our default JSON formatter in ASP.NET Web API. Json.NET provides the ...


16

Well, you can't. As you said, you can represent arrays and dictionaries. You have two choices. Represent the set as an array. Advantage: Converting from set to array and back is usually easy. Disadvantage: An array has an implied order, which a set doesn't, so converting identical sets to JSON arrays can create arrays that would be considered different. ...


15

JSON has a few advantages: It's a structured format, which can be validated and parsed with existing, mature tools. It can speak easily to JavaScript, which makes it very useful for AJAX communication. It's extremely simple and lightweight. Anything you'd want to use XML data interchange for, JSON is generally a better alternative. My rule of thumb is, if ...


15

If this is JSON, you should really consider returning an Array of objects. This has many advantages including that when you have no records it is an empty array. So when you have records, you would be returning: [ {"name": "Ghostbusters"}, {"name": "Indiana Jones"} ] And when you have no records, you would be returning: [ ...


15

multipart/form-data is a construct created for HTML forms. As you've discovered the positive of multipart/form-data is the transfer size is closer to the size of the object being transferred--where in a text encoding of the object the size is inflated substantially. You can understand that internet bandwidth was a more valuable commodity than CPU cycles when ...


14

If you execute operation successfully, but it doesn't have anything to return, such as empty map {} or empty array [] I would prefer to respond with 204 response code, here is excerpt from HTTP Status Code Definitions spec: The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. ...


14

This is one of those basic questions when it comes to REST API design. Every designer asks themselves this question on the first day. Sorry but the answer is "it depends". Each approach has pros and cons and you'll just need to make a decision and go with it.


13

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


13

Is it less efficient to store a small bit of data like your example encoded in a string than as binary? Yes. How much less? Not enough to care. Is it less efficient to store thousands of such records in a string than in binary? Oh god yes. Here's why: I can't predict the index of "account1" in the 42nd record because the fields of the previous records didn'...


13

Depends on whether your available eras are available to the calling application. Presumably they are so the user can select what they're interested in. If that's the case then it's a front-end issue to supply an "ALL" option. If it were me, that would have it send a list of all eras rather than an "all" option. If not, then you need an "ALL" option and ...


12

The decision of whether to use relational DB or non-relational (document/OO/graph) database should not be based on the representation of the data (JSON/BSON/XML/...), but on the operations you intend to preform on the data. If you have a strict schema, and you need to execute SQL queries - You should use relational DB. Otherwise, you may consider other ...


12

I think YAML is best fit for your case. To my understanding, YAML is the de facto standard format for configuration files that need to be edited by hand. Many programming languages have a library for reading and/or writing YAML. JSON is closely related to YAML, but is little bit less easier to write than YAML, and is used more for communication between web ...


12

Can we change XML format (i.e. create a new language which doesn't have the verbosity issue)? Yes, we can. In order to completely migrate to the "better XML" (let's call it BETXML), it would require to: Reimplement all the parsers, Rewrite all applications which currently use XML, Rewrite all protocols based on XML. Or we can keep everything in place, and ...


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