Hot answers tagged

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


5

As always, one must differentiate: what information is to be stored in the cache? I always go with these simple rules: Information every webserver instance can calculate for itself should go into an in-RAM cache as these need to be accessible ASAP on request but have no need to be shared (never change or do not contain information relevant to other ...


3

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

This looks like it will eventually bite you in the behind, as in that it's very cluttered and doesnt really provide good maintainability. I would have organized it like this: Each resource (model) gets its own class file containing its attributes, like: Model/Article.cs Id Name Price Each resource collection has a class containing methods for ...


2

If what you are after is the elimination of global state in your application then the static keyword definitely sucks to have in your code (you say you don't like it, so I'm going to assume you know the disadvantages the static keyword brings to application development). Considering the cache issue, whether it is in-process or out-processed to a system such ...


2

It also happens in web developments. So often. Webservice data model should not be conditioned by UI. It make it really unflexible and hard to scale. In terms of web developemnt, in MVC pattern, C (Controller) is the facade in charge of transforming any business data model into a DTO. Such DTO's are neither designed for UI. They are a summary of the real ...


1

Also, don't be afraid tot tell me it's a silly idea. It's a silly idea :P And here's why: Data caps. The primary hog when it comes to data are things that happen in the background without any user's consent. You wouldn't want to be leeching off a person's data. Battery and heat. Of course, processing takes up resources and resources doesn't come free, ...


1

In your case where you are using microservices you should use the shared cache. The reasoning is that one of the key benefits of microservices is that you can scale them to multiple instances. If you do this and an incomming request hits service instance 2 instead of 1 instance 2 could benefit from the cached result.of a previous call to instance 1 Unless ...


1

Common solutions to this class of problems: Use HQL. In DAO methods that are for specific purposes, it is easy to use a custom HQL with (left) join fetch to specify exactly what data you want to pre-populate in the model. Manually reference lazily loaded collections. E.g. manually call user.getOrders().size() in some DAO methods. This has the same effect ...



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