Hot answers tagged

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


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?


3

It's very typical to use the domain model as the resources in the web API layer, but it's usually not the right thing to do. The domain layer has clients, including the web API. The web API has clients, including your UI. The needs and wants of domain clients are not the same as the needs and wants of web API clients. Write your web API for your clients. If ...


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


3

It should be unnecessary to use sessions for this scenario. When the client creates a new Tournament resource (represented in JSON) it can PUT or POST that resource to the server. Which one you choose will depend on who is responsible for the unique identifier for the Tournament. If the client already knows what the URL should be for that Tournament (say it ...


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

You asked: Does local applications running on the same machine that host the server, will have faster REST communication? Absolutely. Your data won't have to be serialised onto the wire. For faster "local" REST communications, does a server needs to expose 2 endpoints (one for localhost / one for remote) ? No. Your server will expose on a ...


2

First off, the token approach seems sound for your case. One option is to encrypt user information (e.g. id) into the token. On the server side, you can then keep things stateless. Realize that no matter the details of how it is generated, this token is sensitive. If someone has it, they can use it to pretend to be that user as long as it is valid (just ...


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.


2

what would be wrong with treating a client session as a resource/an application state as well? There is nothing wrong with that per say, the problem comes when you try and use application state (in the form of session resources) as a form of authentication. You are basically saying that if the application is in this specific state then this client (say ...


2

what would be wrong with treating a client session as a resource/an application state as well? The short answer is that you get unexpected side effects when the client's understanding of application state and the server's understanding of application don't match. Review Fielding: Section 6.3.4.2. Notice that, in the examples that you describe, the ...


2

I will try to be exhaustive about the possible solutions that you might use. As you wrote, I consider that a product has the following attributes : id, name, availability 1. Designing a resource for each attributes /products/555/name: GET returns the current name of the product id 555. PUT newname modify the current name of the product id 555 with newname ...


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


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


1

Is there a recommended way to handle this scenaio? You need to review Jim Webber's talk on DDD for Restful systems. The basic plot - to modify your aggregates, you deliver documents (aka messages) to your HTTP endpoints, and the changes made to your aggregates are a side effect of the document manipulation. So solution (a) is heading the right direction. ...


1

I believe IP spoofing is possible, but it is very difficult. You either need administrator access in one of the servers in the same subnet as the client, or access in one of the router between your server and the end server. If you use HTTPS, the password based authentication would be enough, no one could capture the password in transit (assuming SSL ...


1

Sessions are temporary data needed by an application, and are usually orthogonal to what the API is doing. Adding session management in the API distracts from the core functionality, and could introduce unrelated bugs. The best place for session data is in the application itself. However, there's nothing to say that you couldn't make a separate API to ...


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


1

Don't really know the full use case but this really screams using a session to me. Normally these are implemented with a unique ID sent to the client in the form of a cookie and stored on the server in an in memory database like redis or memcached. When a user logs a new object will be added to redis and stored by a unique key with any user information ...



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