New answers tagged

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


3

You should return a 404. You can do it by throwing a NotFoundException (https://jersey.java.net/apidocs/2.6/jersey/javax/ws/rs/NotFoundException.html). Also please look at this SO question if you need to control the returned content type http://stackoverflow.com/questions/23858488/how-i-return-http-404-json-xml-response-in-jax-rs-jersey-on-tomcat


3

HTTP 204 means that something was found, but it's empty. For instance, imagine that you're serving log files through HTTP, with the requests such as http://example.com/logs/[date-goes-here]. On May 18th, 2015: http://example.com/logs/2015-05-19 would return HTTP 404, which means that there are no logs, because, well, it's difficult to log the future. http:/...


0

When you call an API through https, you can get the following answers: Internet is down. Cannot connect to the server. https failed to negotiate (after reaching the server). A nonsense answer when you use http in a Starbucks. The server tells you that the API is currently down. The API tells you that it isn't working right now. The API gives one of many ...


0

I don't think there is a definite right answer. It depends of course. If I were you I would think about what the ideal user experience would be when this happens. Then do whatever it takes in your application to make that happen. You could just throw an error and tell the user to try again later. Or if it's an issue that happens sporadically, just retry the ...


0

If you can't rely on the 3rd party API to give you a response (and you're accessing it synchronously) you can set a time-out. I would access the 3rd-party API on a separate thread (or even process) and wait for the response with a time-out set. If the time-out expires, just move on. Additionally, I had a very similar problem a while back. Feel free to check ...


0

If you're giving flow of control to the API the response is to wait until hell freezes over, or the user presses ctrl-alt-del. If you're calling it asynchronously the typical strategy is to timeout. If the API throws an exception, easy: clean up, log, and display the error. Whatever you do, don't fail quietly. I hate debugging things that fail quietly. ...


0

Perhaps you could have something like this? @service('some-service-name') def action(client, data): # action endpoint do_stuff() return @service('some-service-name') def connect(): pass @service('some-service-name') def disconnect(): pass The 'service' decorator takes a single argument, which is the service name. You could use the '...


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


2

You are leaving the radios turned on practically the whole time and this will undoubtedly use up battery. I do see your motivation, however. A decent compromise is to assume that the app is online unless it turns out not to be. If it turns out not to be, and it would like to be, then poll for a connection at long intervals, lengthening as time goes on. 1 ...


0

As long as performance isn't massively important to you you could always run it in Brython which effectively puts it in the JavaScript sandbox


4

Using a background service won't really help you. The problem is that after a succesful check for wi-fi and server you can't be sure that they are still online while you make your call to get the online data because they may went immediately offline after the succesful check. A better alternative would be to just try to get the live data and if this fails ...


1

I am not a lawyer but my understanding is that as long as you are not distributing the software, you don't need to do anything special. You are free to use it for commercial uses. This license was created before the concept of the cloud and the AGPL was created to address this loophole: http://www.gnu.org/licenses/why-affero-gpl.en.html


2

I think you're overthinking things. You can use a traditional SQL-based RDBMS. It may or may not be fast enough (although I suspect you're worrying prematurely about optimization), but the only way to tell would be to try it. Just make sure that you write your code that interacts with the storage system in an abstract-enough way that it is simple to ...


3

It's common for DAOs to return the newly-created resource, particularly when an ORM is used behind the scenes, for a couple of reasons I can think of: The returned object often has its surrogate primary key set, but more importantly - The returned object is often attached to the database session so further changes might automatically be committed when the ...


3

For performance reasons, it's nice if an HTTP API call that creates a resource returns a representation of that resource to the client. Otherwise they have to do a separate GET call to get the resource. The success or failure of the request should be conveyed by the status code in the response - 2xx codes for success, 4xx and 5xx codes for errors. You ...


1

"Idempotent" means that making the call has no side effects. If the call can return an error, then it can return an error on the first request, the second request, both, or none. You might have an access token that is valid for 24 hours; a request one millisecond before the token runs out succeeds, a second request one millisecond later will fail. ...


2

According to the HTTP 1.1 specification, idempotence is defined as: "(aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request". As this definition only discusses the side-effects of the request, and not the content returned, it is acceptable to return different content.


3

You can return an error on the second put and still be idempotent in the meaning of the term when applied to the http operation PUT. In this case the idempotency refers to the end result on the server of your operation. Ie if you send two identical PUT requests only one should be actioned. The clients action on the returned result is not part of idempotent ...


2

I would argue on the side of the service/scheduled task to update the data. Your web application can become dormant, or unused for a period of time. IIS will at this point put all instances of the worker processes running your application to sleep. Speaking of instances of worker processes. They are completely unaware of one another and having multiple ...



Top 50 recent answers are included