If you're providing a web service that provides Add or Amend functionality for records in a database that has a unique key why would you not provide an "Insert or Update" method, in addition OR instead of two separate methods for Insert and Update?
I'd be grateful if anyone could suggest what benefit the two separate methods provides to the client?
Currently I'm focussed on the negative of forcing the client to have to hold state or to perform one request and then the other should it fail.
Having to store state, in my opinion, feels more prone to error.
To avoid unwanted overrides.
When you intend to create a new record but instead override an existing one, data could get lost.
When you don't read the record before an update, there is no point in separating the two operations.
It depends on your situation.
Related
I have a Django app with two models linked by a many-to-many relationship.
Service, problem_type.
A service provides assistance for a number of problem types. I use the problem_type table to later facilitate lookups of all services that help for a specific problem type.
I update my model from an external API. I take in a list of "problem_types" for each service, eg:
['housing', 'financial aid' ... etc]
Over time, a service might get new problem_types or remove old ones. Is there a best practice for managing this?
Adding new problem_types relationships or new problem_types is ok, I just loop through the incoming list of problem types and add any new ones to the problem_type relationship/table, but what is the best way to remove now redundant ones?
Is it best to:
Loop through associated problem types and delete each not in the new incoming list?
Get all associated problem types and delete every relationship before re-adding the incoming list
Is there some built-in method for doing this that I have not been able to find?
In an ideal world love to be able to pass the incoming list of new problem_types with the current set of related problem_types to a method and add/remove as needed. Does something like this exist or do I have to implement it?
Context:
I was going through various guides, tutorials and also posts here in the stackoverflow.
I need to handle process, e.g., - “pick topic —> show author list —> delete all —> ask confirmation —> show result —> go back to author list”
The obvious (and simplistic) approach is to create sets of views for each process.
And save process state in session variables or pass via URL-s (however, I discovered this method can be very brittle if too many information is passed). Also I need to tell each view where to go next, and this mushrooms into a bulky chain of instructions repeated for each URL request.
Instead, I want two extra things:
encapsulate a process at single place
re-use views, e.g. to re-use Topic List view to pick a single topic. That is, to work in “picker mode”. (btw, if I try to do this with multiple view classes, the next view class needs to know what to do and where to return…)
I also checked django workflow libs, and so on. and still not convinced.
Question:
if I create global object to encapsulate process and reference it from the current session - is this a good idea? My main concern is that - as sessions come and go, who will be cleaning up this global object?
is it possible to somehow make this clean up automatic? that is, when session goes away, some method is called where I can clean up or help GC to collect unneeded object? Like C++ destructors?
after working further with code, it occured to me that if I add global object to the session (and nowhere else) - it must be garbage collected in due course, because session itself is managed by Django.....
also, reading https://docs.djangoproject.com/en/3.1/topics/class-based-views/intro/ in my 3rd pass, found that Django's as_view() instatiates a new instance of class based views on each HTTP request.
so, everything is per request basis, and data will be transient. So only way to maintain state across HTTP requests is to either persist in the database or use sessions (or keep passing "state" from each request to request via URL parameters, but it is bulky, unsafe. my understanding is that this is a fallback mechanism if cookies are not allowed and session can be simulated via this way, e.g. PHP does it).
I am new to Django and want to know deeper about the concept of signals.
I know how it works but really don't understand when should one really use it.
From the doc it says 'They’re especially useful when many pieces of code may be interested in the same events.'
What are some real applications that use signals for its advantage?
e.x. I'm trying to make a phone verification after user signup. Because it can be integrated inside the single app and the event that interested for the signal is only this 'verify' function, therefore I don't really need signal. I can just pass the information from one view to the other, rather than using pre_save signal from the registration.
I'm sorry if my question is kind of basic. But I really want to know some insight what is the real application, in which many codes interested in one particular event and what are some trade off in my application.
Thanks!!
Often signals is used when you need to do some database-specific low-level stuff. For example, if you use ElasticSearch for better searching documents on your site, you may want to automatically update search indexes, when new document is created or old one was edited.
Also you may have some complex logic of managing database objects. For example, you may need some specific logic of deleting object. For example, when user is deleted, you may want change all the links to his profile by some placeholder, or when new message is created or other action is performed by user, you want to update "last visited" field in user's profile and there's no direct relation between this action and updating the profile.
But when you're just implementing business-logic as in your example with verification, you don't need to use signals, because you don't need any universal logic related to deleting/creating/editing any object: you have a certain object with which you work and can do stuff directly.
I have got an architectural question. Where should I check user permissions for certain operations?
For example:
1) In a controller, I get parameters from view and start a process in the intermediate model.
2) Intermediate model decide which parameter should be converted and transformed in any way and modify or create data through Models
3) Model communicate directly with DataBase
Where do You think is the right place in that "architecture" to check privileges to for example save sth to database?
I would actually put the authorization check before the controller is being called, kinda like described here (I really need to update that old post). Preferably as a decorator around the controller instance, which would give you a fine-grained control over what operation user is permitted to do, based on controller+method pair.
Another point where you might think about is "authorization lookup" helper function for use in your templates, because you might need to show or hide some UI elements from users, who should not be able to perform the associated operations. The controller+method check, before execution would still work as the actual safeguard then, but it tends to be a quality-of-life improvement.
You should not put the authorization checks inside the each controller or (even worse) model layer, because that tends to promote an excessive amount of copy-paste, which in turn can cause mistakes and becomes a huge problem, when you want to alter the mechanics of your authorization system.
Let's say we have an entity that contains a list of users on the server, and we want to expose this as rest. What is the proper way to do it?
My first guess is something like this:
/entity/1/user/5
We can use PUT for updates and DELETE for deletes?
Is this right? I went to wikipedia where it talks about rest, and their view of it is that everything is only 1 level deep. So maybe they want you to use PUT/POST and give the entire JSON graph and update the entire thing all at once?
Your example is a perfectly valid approach.
However in many cases a User can exist outside of the context of just entity. I tend to identify resources in isolation, e.g:
/entity/1
/user/5
To see users associated to an entity I would use:
/entity/1/users
Adding a user could be done by POSTing a user,
POST /entity/1/users
<User>
...
</User>
Deleting a user would be
DELETE /User/5
Updating or creating a user could be done with PUT
PUT /User/6
Removing the association between a user and an entity requires a bit of creativity. You could do
DELETE /Entity/1/User/5
as you suggested, or something like
DELETE /Entity/1/UserLink?UserId=5
or just
DELETE /Entity/1/Users?UserId=5
It reality is not very important to the user of your API what your URI looks like. It's good to be consistent for your own sanity, it is good to choose schemes that are easy to dispatch with your server framework, but it is not what your URIs look like, it is what you do with them that is important.
I use your method for parent/child entities, but for many-to-many I use an array in my JSON object representing that entity.
So using your example:
GET /entity/1
would return an entity object something like this:
{"entityID":1,"name":"whatever","users":[1,2,3,4,5]}
PUT would pass in this same object, and update both the entity and the users. Then to get the specific user info:
GET /users/3
Using PUT on users/3 would update the user. PUT on /entity/1 would connect users to entities. Unfortunately, there's not not a lot of good info out there on how to model this sort of thing.