Say I have an app for patients and doctors.
Patients should be able to access their information at `site.com/api/patients/.
Doctors should be able to access information about the patients as well, but would receive different information than the patients.
I can imagine two ways of handling this:
api/patients with logic to split between different permissions
OR
api/patients for patients AND
api/doctors/patients for doctors getting information about patients
This seems relatively fine, but then I started thinking about what happens when both a doctor AND a patient can add tasks for a patient.
api/patients/tasks/ for a patient to add a task BUT
api/doctors/patients/tasks Which gets pretty bad as far as nesting goes (Where I believe it might be better to limit the depth of my routes)
Is it simply better to have api/patients and check for whether the user is a doctor or a patient or to nest resources? What is the consensus on best practice (if there is one)?
It would be nice to have API endpoints like:
api/tasks/
api/patients
api/doctors/
which keeps things simple, and then control permissions/authentication with a token or query string.
Definitely don't do api/doctors/patients, etc.
Should this be two different APIs, one for Doctors and one for Patients? It depends on how much overlap of functionality there is.
In any event, you should already be tracking authentication/authorization information for your users. Otherwise you'll have doctors modifying patients who don't go to them. Use the auth info to determine what values/options are supported for the caller.
I assume you're handling the case where I copy Dr. Bob's token/query string and send my own requests?
Related
I have a PostgreSQL database with various relationships between different entities/tables. E.g. teachers and students, teachers and classrooms, students and classes. In my (express) backend*, I find myself writing a lot of tedious routes to extract data - the routes make similar but slightly different SQL queries (we use sequelize), e.g.
get students based on age
get teachers based on school
get all students that learn with particular teacher(s)
get all teachers that teach particular student(s)
get all students that went to a class between certain times
get all students that went to a class between certain times and had certain teacher(s).
granted, the last 2 could be merged into one REST endpoint easily by passing null for a when no teachers constraint. Still, there are many many more permutations and that number is only growing with new entities.
To speed up development, I am wondering if (i) GraphQL would buy us anything (we have ~30 routes today) (ii) if it is even possible to setup and use GraphQL to somehow connect to my postgreSQL (and redis) database without doing a LOT of boiler plate work.
I have had a look through the Apollo docs (https://www.apollographql.com/docs/tutorial/data-source/), and looking at SQLDataSource (https://github.com/cvburgess/SQLDataSource), it seems that I still need to write/expose endpoints for every one of my scenarios - e.g. if i want to find which students have which teachers I still need to write a manual SQL query to do that and expose that as a method on a SQLDataSource object. I presume I am misunderstanding something here as I thought this was a key value proposition of GraphQL.
Thank you so much!
*we just have 1 service today but are adding another shortly
Based of you requirements, I only see three endpoints, one with few query params but nothing so complex, as example:
GET /students
GET /students?birthdate=<birthdate_year>
GET /students/<student_id>/teachers
GET /students?class_dtstart=<dtstart>&class_dtend=<dtend>
GET /students?class_dtstart=<dtstart>&class_dtend=<dtend>&teacher_id=<teacher_id>
GET /schools/<school_id>/students
GET /teachers/<teacher_id>/students
I think that you can play to few endpoints with some params to build the query that you want in a clasic rest api schema. Obviously you need to write somo code to transform que route params to your SQL query but I think it is not very complex.
I'm currently learning the second part of object-oriented programming and we have moved on to UML. We are learning about use cases and actors currently and we need to create: List of actors and use cases initiated by each actor for a given problem.
I understand what each of the individual components are but we haven't been given any examples. I've looked up examples but it only seems to give the final result of the use case diagram. What I am struggling with is using a problem statement ( the requirements of the system) to then create and find the actors and use cases:
https://www.scribd.com/document/401208954/Pms
This is my example of what I think to do but not sure if im on the right track...
2.2 MONITOR Each bed has a separate monitor that collects patient data, sends information to the display, and responds to user commands
and queries.
The requirement is going to be: collects patient data, the goal: sends info to the display and the owner: the patient????
First, you need to find in your document the actors who use the system and initiate interaction with it. These are the primary actors. For example:
1.PURPOSE
Blablabla... The users of the system are nurses and doctors
Then you need to find in your document any secundary actors. It's the actors that might be involved in an interaction in the system, but as a participant, not as initiator. For example:
3.1.4 ECG AND HEART RATE (HRT)
The ECG signal is carried by cables connected to electrodes attached
to the patient's skin.
Here, clearly, the patient is involved, at least passively.
Attention, primary and secondary actors could also be systems, that would be independent of the system under consideration (e.g. a central admission system that would feed the system with patient data). I'm not sure that we have this case here.
Then you need to go again through your text, keeping the primary actors in mind, and looking for what they could want to use the system for. That's the use case, and it should in principle correspond to an actor's goal. For example:
3.1.8 PATIENT ADMISSION AND DISCHARGE
In order to blablabla..., the patient must be admitted. Patient
admission consists of blablabla....
3.3 EVENT RECORDING
The user must be able to input textual remarks on the patient
condition. Blablabla...
In these examples, the users will definitively want to admit a patient, monitor the vital signs of the patient, and record events. The difficulty is to filter out what the users want to do (the goal), and the details of how they do it or how the system looks like. For example, entering the name and age, plugging the ECG cable, or the NBP are operational details of the admission.
Some of those details are purely descriptive (where the info will be shown on the screen), but some details could be a secondary goal (a subgoad for the user, in order to achieve a higher level goal). For example silencing the monitoring. You may list those as a use case, but you should then note that it's not a top level. These details are only needed when refining the main use cases.
Then you may associate secondary actors to identified use cases where appropriate.
We are trying to write an authorization program to our company.
We've decided to use claim based authorization .
The normal restrictions are pretty easy (Let particular users use particular services ETC) , but I have some kind of special requirement :
I need to filter records of the result set, based on the claim this user have.
For example , I have a service that return a list of people that invest in our company, with details about them and the amount of money they have. Now, an employee shouldn't be able to see other employee details, unless this employee is a direct manager of the employee presented.
This means -> I need the claim attribute to some how effect the result set, and I couldn't find any information online on how to do this.
What you're looking for is usually called fine-grain security, and HERE is one article on doing it with ASP.Net and claims. Also, a search for "asp.net fine grained permissions" will lead you to lots of resources.
This is a pretty involved topic, but it basically involves elegant and effective ways to add filters (e.g. WHERE clauses on SQL queries) to accomplish your row-level application security.
Ok, my last question had no answers, so I've the doubt that I'm walking on the wrong way.
I'm developing some Web REST Api for a mobile application, and regarding REST best pratices I don't know how to face a many-to-many relationship.
I have two tables, Wallets and Cateories, between these tables there is a many to many relationship since a category may be associated to different wallets and a wallet may own different categories.
Actually this database is used by a non rest website:
when a user creates a new category, he choose from the list of his own wallets which wallets to connect it to, and with this single POST call the category is created and conneted to the wallets.
I don't think that replicating this behaviour is compliant to REST best pratices.
My first idea was to "expose" the connection between categories and wallets with this form:
http://localhost:8000/categories/77/wallets/4
but I had the problem I wrote on my previous question, and I don't think this is the right way.
Anyone has a valid method to manage a many-to-many realtionship according with REST best pratices?
Thanks in advance.
Namespacing wallets by a category is fine, as in /categories/77/wallets/4. You can also consider a more concise scheme like /categories/77/4 or /wallets/77/4 if there are only wallets in a category.
However, you don't have to namespace. Your wallets presumably have their own IDs, so you could also just expose them as /wallets/4.
Is it worth the effort? I think it can be a good practice if your URLs are also on a public website (in which case you would probably want to support slug IDs as well, e.g. /categories/luxury/wallets/acme). If not, you should be aware it will be a little more configuration work on the server-side and a little more work for clients (clients will have to be aware of 2 IDs instead of 1).
I'm trying to make the domain model of a management system. I have the following kind of people in this system:
employee
manager
top mananger
I decided to define an User, from where Employee, Manager and Top Manager will specialize from.
Now, I don't know what kind of specialization hierarchy I should choose from.
I can't decide between the following ways:
or
Which might be preferable and why?
As a long time coder, every time I try to do a domain-model, I have to fight against the idea of trying to think in how I'm going to code this. From what I've understood, I should not think about those matters in the domain-model, only in object relationships. I don't have to think of code duplication or any of these kind of details here, so I can't really pick any of the options over the other.
Thanks
EDIT:
I'll be a bit more explicit: This is a program to manage worker's vacations plans. With this program, a employee can choose the set of vacations days for the year. Then the manager might approve or not those days for each one of the employees and at the end of the day the top manager should approve or disapprove the manager's decisions. This is all the users of my program are supposed to be able to do. There are no other tasks.
This mostly comes down to a question of how you define your terms. The basic question is whether a manager can be substituted for an employee under any possible circumstances -- and without knowing the precise rules of the workplace being modeled, it's impossible to say one way or the other about that.
One general notion is that yes, at least up to a certain point, in a pinch a manager should be able to do the job of any of his subordinates (at least one level below, and quite possibly two or three).
On the other hand, in some places with lots of union-driven rules in place, that may not be the case at all. Even if a person is entirely capable of doing a job, rules may prevent him from substituting in that position at all. In some cases this arises from certification requirements and such (e.g., the manager may have one been qualified to do the work, but the required certification has lapsed) or from things like union rules (e.g., a friend of mine who was once reprimanded because he carried a flashlight bulb and battery from the company store back to his lab instead of getting a union materials handler to do that for him).
In real life, Managers are Employees too. So this is surely just a chain of increasing specialisation:
User -> Employee -> Manager -> Top Manager
edit
"This is a program to manage the
vacations plans of workers."
In you company do Managers take planned vacation? Surely they do. And equally surely you are not going to build a separate application to manage that. So what you really need is this:
User -> Requester
-> Approver
Each User will be a Requester in one approval chain. (You may need special arrangements for the CEO). In addition some Users will be Approvers in one or more chains. The final approver will probably vary depending on the grade of the Requester: the CEO won't want to bother themselves with approving the vacation arrangements of the janitorial staff.
You will need some rules to enforce who can be an Approver of any given Requester's holidays. Unless you have an exceedingly flat organisation you will find you have a hierarchy of workers and managers. For instance, a Team Leader or a foreman - individuals who are in other respects "workers" rather than "managers" - may be in the chain. Also you may need to consider other aspects of the organisation. Fr instance, if the employee wishes to carry leave over to the next year that may require approval from the HR dept, somebody who normally has no managerial responsibility for the employee whatsoever.
Edit 2
Okay, so we are modelling an arbitrary set of rules rather than a realistic scenario.
Let's see. Each User fits into a single category, defined by these tasks:
an Employee can Request leave
a Manager can Approval or Reject a Leave Request
a Top Manager can Accept or Overturn an Approval or Rejection
Managers and Top Managers have no behaviours in common. Consequently, the first model is the correct one.
I would model these as actors. They are not the domain of the system, but the users of the system. Would you model a shop's inventory system with 'school-kid who wants sweets', 'school-kid's parent who wants tobacco', 'clerk' etc? Although only a store manager (actor) can give refunds without a receipt, what matters at the system level is that system recognises the store manager's key, and it's that permission token which is in the software rather than role the actor takes.
The domain of the system you describe is vacation requests and the user account, and some of the use cases mean that some of the accounts have permission to perform certain state transformations to a vacation request.
The difference in modelling User/Manager/Employee as actors and roles is that you can focus on modelling what you need to put into the system, as don't have to have hierarchies of actors - you start using abstraction at the use case and system entity levels, rather than in the actors. It's not always a bad idea to think 'how would this work in code', at least as far as asking 'why bother coding this distinction'.