Hot answers tagged

7

I would keep each library in its own repository. Start keeping track of library versions, for example with git tag. A big problem with simply checking each library into each application's repository, is that you've essentially done copy and paste, and thus gain all the disadvantages that implies. Bugs fixed in the copy of the library in one application ...


3

200 OK Always returning "200 OK" is a terrible practice. It really kills anyone trying to write a client against the API. REST client frameworks rely on accurate status codes and will break if they receive "200 OK" even when it's not OK. The author of the REST client will have to jump through hoops to make it work correctly. As a case study, I was recently ...


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

There are two basic approaches that you can take. Keep versions on libraries. Track dependencies carefully. You will eventually experience dependency hell. Keep all libraries up to date all the time. You will need very good unit tests, and a deployment strategy that provides a locked target for production. I have worked at companies that use both ...


2

If your data source does not provide you with notifications when data is deleted, then I don't see any other choice but to brute-force the solution by polling the source periodically. Depending on the data source, this may violate terms of service if you poll too often because it puts a heavy load on the source server. The ideal solution is to work with ...


1

After a lot of back and forth and discussions with colleagues i have settled with option 2. Here is why: The strategies are equal functionality-wise. The race conditions are what causes trouble. We anticipate these race conditions to occur: Multiple devices of the same entity initially request a token [in a very small timespan] Multiple devices of the ...


1

For any parameter for which your application has to interpret the semantics, your option 1 is IMHO the better one since it is simpler, more expressive and the additional flexibility of your option 2 does not bring you a benefit, since when you later introduce new, additional parameters you would need to change your application either. If some of the services ...


1

I have answered this question on StackOverflow as well - I place my answer here for easy reference... The PRG pattern alone will not prevent this, as the P action in it takes time (which is usually the case) and the user can submit the form again (via click or browser refresh), which will cause the PRG pattern to "fail". Note that malicious users can also ...



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