Hot answers tagged

11

Short answer The map is not the territory. Longer answer - as with anything REST, the place to start is with Roy Fielding's thesis; in particular chapter 5. For your current question, you want section 5.2.1. REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; ...


9

The user is the resource and if it's not there you return 404 resource not found. The URI is the representation of the entity. That's the whole point. 404 means the server was contacted and they couldn't find a resource and it returns 404. If you are getting a server side error, there's a whole range of errors for that in the 500 range and that is what ...


7

You call GET /reports/{id} with either an If-None-Match or If-Unmodified-Since header set. The server determines if it needs to recalculate or not. If not, it returns a 304 NOT MODIFIED. If so, it recalculates and returns the new report in the response body. I should note that in the question, but recalculation takes a time. E.g. up to 10 minutes. So the ...


4

There is a gross misconception somewhere. I think it is near this idea. In Spring+JSF application all the business logic was encoded in special layer - Spring entities and services. In Spring+REST+AngluarJS this should be different. I don't want to rewrite (move) business logic from Spring/Java to AngularJS/JavasScript but obviously I am required to ...


4

REST maturity levels and DDD are orthogonal concerns. Your Ubiquitous Language doesn't care whether it's reflected deep down in the payload of a SOAP message, in a resource URI, or in a domain-specific content type, as long as it remains pervasive and coherent throughout its Bounded Context. If your Bounded Context includes both the client and server ...


4

I think 409 is a good choice there if the conflicted state was achieved by another client sending in a PUT i.e. A does a GET B does a GET B does a PUT state is now different A tries to do a PUT but the new state is not possible so A gets a 409. This only works if the server can determine the bad state transition, either from FSM transitions that are ...


4

Short answer is that 404 is the correct way to go. Long answer is that the HTTP status codes relate to state transfer between the client and the server, and are NOT designed to indicate any issue with the server's database data model. The server is for the most part a black box to the client when it comes to the HTTP layer. To clarify my answer I'm going ...


3

I would go with something like the following. A path parameter gives you a unique uri for a resource like /userinfo/user/123 Where 123 is the user id. Here I would return 404 as the specified resource did not exist. You could also validate the id and send back a 400 (Bad request) if the user id that was sent does not match a given pattern. If we instead ...


3

Here's a problem with your proposed approach. If you send the requests over HTTP, a 3rd-party can snoop the traffic and pick out the authorization token. Then they could send their own requests to the end-point using the token. Solution: use HTTPS rather than HTTP when doing the initial authorization to obtain the token, and whenever you use the token. ...


3

For the first question, your approach seems correct to me. You consume a token in the sendsms entry that can only be generated by the login endpoint. You could also use a generic token created by login, and not easily guessable (it would be equivalent to a cryptographically generated session ID), used as primary key to a database tuple. There you can store ...


3

If you GET the same resource at the same URI, what do you expect to get back? Do you expect to get the same multipart content that you sent, i.e. the data and the file, or just one of them? If it's the latter, then it's not a RESTful use of PUT, since one URI no longer refers to one resource. You would be better off considering using POST, or splitting the ...


3

Your business logic should remain untouched. The Rest API is a view. The UI is a view. At most the controller should change to accommodate this change. In an ideal design the controller would have no knowledge of any views and wouldn't change at all. Rather than showing the flow of information it would have been helpful to see the directions of ...


1

It all depends on what the GET in the api is doing but I think it is restful to have a multipart PUT. The type of the payload doesn't change semantics of what a PUT is in REST. For example if I had an Amazon S3 like REST api it would be restful to update the file content if a multipart PUT was made on a resource.


1

For the reads: My usual answer is that track each "report" with several ids. For example GET /reports/{id}/latest is going to redirect to, say, GET /reports/{id}/latest?asOf=2016-05-17T12:00:00%20-0500 These resources always refer to reports where the processing has been completed, so there is never any waiting to be done, the representation of the ...


1

A resource is the thing that you are working with. For example, if you have an API for switching a certain lamp, then the resource is the lamp itself. A resource can be physical (e.g. lamp, person) or non physical (e.g. article, role, a row in the database), a resource can be primary (e.g. balance) or derived (e.g. transaction). A resource can refer to a ...


1

A resource might be an invoice. A representation is an invoice at a specific point in time in JSON format, or in XML format. You might get the exact same invoice at a later date it will be the same resource but in a potentially different state (cancelled, paid, etc). You take the current state of the invoice (eg: all the invoice data in the database) and ...


1

One of the core design goals of Websockets is that it allows both HTTP and Websocket protocols to be communicated over the same port. It achieves this by explicitly requiring a client to perform a Websocket handshake with an HTTP Upgrade request. In this way the server can handle a standard HTTP request connection as well as an HTTP Upgrade request that is ...



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