New answers tagged

0

I don't know what kind of objects you are serializing, but generally speaking, a binary serialization, combined with something like LZ4 compression, makes much more sense than JSON.


1

The proper HTTP error code on input is 400: Bad Request. In the response you could go with 500. If there is an error in marshalling or unmarshalling, an exception will be thrown which you can handle by registering an ExceptionMapper (scoll down to the Exception Mapping section). You can then determine what kind of error to throw. The JAX-RS package has a ...


2

For your case, I believe returning { "status" : "off" } With a 200 status code is "correct". In practice, it doesn't matter much. When Fielding published his famous rant on hypertext, he called out a particular error in this way: Failure here implies that out-of-band information is driving interaction instead of hypertext. Out-of-band in this ...


2

From my understanding, the solution 1 misunderstood the semantics of the HTTP status code. From RFC HTTP/1.1: Status code Definitions 10.4 Client Error 4xx The 4xx class of status code is intended for cases in which the client seems to have erred. In you example, it's a matter of resource representation. Because you are probably thinking that a ...


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?


1

Disclaimer: This answer disagrees with the current accepted answer. Keep an open mind and see why. We're all just trying to share knowledge here anyway right? Skip to end for TL;DR For anyone stumbling upon this now, this answer tries to stick to the design pattern of MVC in context of the web defined simply below: Model: the data persistence layer View: ...


0

Rather than attempting to answer the entire question, let me offer a concrete way to share data: just use any mechanism (jQuery, ajax) available in your implementation language that lets you call your webserver. Use a GET call to get constant data with automatic caching. Use a POST/PUT calls to get/set variable data. You can use other request methods, too, ...


0

This is a really nice question. The problem arises because you are modeling redundant information and try to avoid redundancy at the same time. On the one hand, you have a collection of players players = [{"id":"1"},{"id":"2"},{"id":"3"}] On the other hand, you have a colletion of teams, which itself consist of subsets from players. teams = [ {"id":"1"...


0

For inspiration, you may want to look into the way some of the json based api's (ex: json api, HAL) handle embedding. One simple answer is to track your data in a key value store. For example { "/players/0" : {...} , "/players/1" : {...} , "/players/2" : {...} , "/players/3" : {...} , "/teams/0" : {...} , "/teams/1" : {...} } And then you describe the ...


1

You say these are key / value pairs. In that case, use #3: dictionary of key / value pairs. If these are not key / value pairs, then don't call them "keys" and "values" and use #2, an array of dictionaries with arbitrary contents. Structure #1 is just daft unless you need key / value pairs but also their order. Which you rarely do.


1

The 3rd format is in general the best. However, here's an example of something suitable for the 1st format: [{ "username": "foo", "id": 1 }, { "username": "bar", "id": 2 }, { "username": "baz", "id": 3 }] Here each object refers to a separate thing (and each object uses the same keys as the others, so they couldn't be merged). However, each ...


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


1

Put your self in the shoes of the person receiving the json. If i don't know the key name how am i supposed to retrieve it with the first or the last format? You can loop through the json of course but since all three formats achieve the same result it's just a question of syntax. I think this is the only meaningful question: if you know the key names the ...


2

In a JSON "object" (aka dictionary), there are two ways to represent absent values: Either have no key/value pair at all, or have a key with the JSON value null. So you either use .add with a proper value what will get translated to null when you build the JSON, or you don't have the .add call.


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


1

JSON API is nice, but complex spec. Its implementation is also not easy, especially if you don't have good library implementing it. So it's mostly a question "is it worth it for our use case"? In my opinion, it's worth it if you have large and/or public API which needs to be stable, extensible, will be developed for years. JSON API provides reasonable ...


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


0

Would you like to be able to dynamically add new content and functionality to your client without having to change it? If you go with Json API (and actually leverage it), you can accomplish exactly that. Let's say v1 of your book resource looks like this links: { self: "/books/1" next: "/books/2" } author: { links: { ...


-1

I'm currently dealing with a SOAP API and it's corresponding WSDL. After looking over the JSON API specs. I get the impression that they are trying to be a WSDL equivalent for REST JSON servers. Like WSDLs, the JSON API is not the most readable in the world (although more readable than WSDLs,) but is meant to be parsed by tools that will then create the ...


0

I'm not interested in JSON, I'm interested in the objects that are created from JSON. Like in your example, turning plain JSON into objects is easy. How difficult is it for new developers? Mostly they are interested in the objects created. They can look at the code that turns JSON into objects, which is trivial. I looked at the JSON API spec, and I wouldn'...



Top 50 recent answers are included