Tag Info

Hot answers tagged

78

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


28

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


14

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


11

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


11

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


10

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


10

Because you can do many more things with real data besides display it in a web page. HTML is just a type of output that web browsers recognize, and it's not really useable as data in a meaningful way, because its metadata is about structure and form, not about the data itself. It also contains all sorts of things that have nothing to do with data output, ...


7

There are really two definitions of REST: Representational State Transfer ("REST") as a principle for service design (not necessarily web service!), which suggests a uniform client-server interface where the server does not store the client context, e.g. "client has visited this page last". As a general principle, RESTful services shuold request a ...


7

I fail to see the big gain with the </> variant. Are you talking about readability for the human eye? In that case I would take ordinary XML any day rather than trying to figure out what the code is trying to tell me when I see something like this in the middle of a file: ... </></></></></></></> ...


7

I would go with 2. create a table Sub-pages which references it's parent section by a Foreign Key When you have to do such Sections Sub-pages like things then I would go with creating separate tables so that it becomes more efficient in organizing the data. There's one scenario that I know which I would like to tell you. If you store all the ...


7

Note that the license refers to the reference implementation of JSON, not to the JSON format itself. As an aside, I find it amusing that people get so worked up over the "not evil" clause. See this Douglas Crockford video for some perspective.


6

There has been a reasonable amount of work done on creating a standardised JSON API format. Following the principles in that specification mean that all resources returned should effectively be "collections" (even when just a single resource is included). Following this would mean that your call to /v1/get/movies would return: { "movies": [ ...


5

Most of the web apps I've written for my firm works this way -- a single page, javascript driven application making ajax calls to a back-end service. So when I started my own website, my first implementation was done the same way. However, more than halfway through the development, I realized I made a big mistake. My website offers content to my users, and ...


5

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


5

JSON representation can be dense, certainly denser than a flat list of properties, so memory exhaustion and denial of service may be slightly easier. Other than that, assuming your JSON parser is bulletproof, you're left with basically the same attacks that can be directed at a form-data or query-string based entry point, primarily various kinds of string ...


4

What do you mean by "good idea"? Good idea for whom? Does your company have pots of money to spend on the whim of an architect? Using ajax techniques can provide a much better user experience, there is no doubt about that. Are your end clients, whoever they are, complaining about the way the app works? Is this just going to be part of a rewrite that is ...


4

It's all about the trade off between the size of transmitted data (and hence the time taken to transmit it) and the ease of converting it to / from your class objects. A hand crafted binary format will have a smaller size then JSON or XML, but will that require much more effort to code and test routines for serialisation / de-serialisation. Just about ...


4

If you were defining common error format for your Api, see also "Problem Details for HTTP APIs". You don't need to say "status: fail" because it should be indicated already in status code. You can use "problemType" URI as key. For clients that don't want to translate error message themselves, they should use Accept-Language header so server knows what ...


4

JSON is a data interchange/serialization format. It's not code intended to be written by humans, but human-readability is important. Given these requirements, JSON is the simplest subset of JavaScript that could possibly work. For example, we need to allow quoted keys in objects. But if we already have a quoted syntax, there is no need to support unquoted ...


3

What do you mean by "RESTful JSON API" - I think the first issue here is that you are mixing up concepts (or possibly someone between you and your technical counterparts at your "suppliers"). A RESTful API (whether you're talking not at all rest really at level 1 or something at level 3 or above c.f. ...


3

Should I return HTML, then make another AJAX call for the response? Unless you have some compelling reason not to (there aren't any I can think of), you should definitely favor minimizing the number of calls. Each call has the overhead of URL resolution/etc. and if you're just getting the same data you'd send anyway in the single call, there's no reason ...


3

JSONP is not technically a thing, it's actually just Javascript. So it's not JSON but Javascript object initializers. If you notice, Google's response does not run as Javascript code nor is it valid JSON. So it doesn't do anything if a 3rd party site includes it as a script. Those are not 2 JSON objects for sure because the keys are not quoted. They are ...


3

The first thing to consider, since you are building a RESTful API, is to return an appropriate response code. And the more appropriate response code to communicate that the request went through normally, but the requested resource is not available at the moment is the venerable 404. If you design your API in such a way that it always returns a sensible ...


3

There are many libraries that will help you serializing and deserializing your data in XML or JSON. CSV is not so popular anymore, so you may need to do everything yourself. On top of that, both XML and JSON are probably easier to read for a human, which makes debugging easier and faster (i.e. cheaper). CSV, on the other hand, has less characters for the ...


3

Coming from a front-end developer perspective, I prefer simple and semantic as much as possible. Generally inside a consistent envelope for debugging and tracking, the actual data would be as follows: { "images" : [ { "id" : 123, "filename" : "someFile.jpg", "caption" : "some image or other", "gallery" : ...


2

I've seen both cases in production environments. Which one you choose depends on who will be using the API. If they want to know why the list is empty or to be sure that the list is really empty and no errors occurred while retrieving it, then you should attach an "errors" object. If they don't care, go with returning an empty list. I'd go with second ...


2

I've also ran into similar issues and I ended up going the other way -- check out disqussharp for visceral details. The tactic I used there was a common base class with variants for things that changed between different calls. I think having a single class -- or at least a common base class with the common properties -- is vastly more convenient for ...


2

A best practice is to keep the reply consistent, meaning you should always have JSON offering a structure which is consistent and provides enough information to infer whether or not the call was a success. First check the ajax status that the command was properly handled. Once you've determined that the command was properly handled, you then proceed to ...


2

Try it. I did a few projects (mostly with angular and web api), and it was a good experience overall. Advantages - you have a very fluid user experience, and can create single-page apps with ease; have a clean separation between business and UI; you can use web service for different apps (e.g. to feed a mobile app, etc - data is data, you can reuse it). ...


2

By all means, it's worth trying out, but know that the learning curve can be a bit steep at times (Javascript is an easy language to hate.) Javascript web apps have some really nice features. For example, you can port your app to various mobile devices as native apps by wrapping the application with Phonegap. There are a handful of options as far as ...



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