I want to make a system for users to specify their own rules for when to receive alerts when something happens in their facebook feed. I want them to be able to say 'please send me an alert when Z happens' and then specify that Z is: 'my friend X posts something that contains Y' or
'my friend X doesnt post anything for two days in a row' or something to that effect.
I want this to be easy for the end-user and allow them to define complex trigger events . Is there a specific method to do that? I know that by modeling the specific entities and their relationships I can probably come up with something. My question is: what domain of computer science is this (some subset of AI?)? Are there generic methods to allow the creation of rules? What can I read before I start?
Thanks
Related
I'm designing a system that talks to multiple servers across different regions. Each of the regions for the same request will return unique results e.g. user a's device configuration might be different in ANZ to EMEA.
A few questions have come up about what is the best way to design the system so we get the most versatility.
Questions:
A function was created so if an API call is made without specifying a region, the results of all the regions will be returned. Is this a smart thing to do or would it be better to force a region to be specified?
What would be the best way to handle regions (ANZ, EMEA, INDIA, ASIA, AMER) in a restful manner. My first thoughts were /region/anz/userid/123, but if we want to do a global search for a user this would require making x amount of calls. Is this the better approach or would it be better to add the region at the end of the URL like so /userid/123?region=anz
My first thoughts were /region/anz/userid/123, but if we want to do a global search for a user this would require making x amount of calls.
The usual answer in REST would be to create a resource that provides a representation of the global search results.
GET /global/userid/123
Would be fine.
GET /global?userid=123
GET /userid/123/global
GET /userid/123?global
GET /userid/123?region=global
These are also all fine. As far as a general purpose component is concerned, the URI is semantically opaque. So you can use anything that makes the human beings happy.
When you have a cluster of related resources, it can be convenient to use identifiers that are easily described by a URI template. See RFC 6570.
On the web, the common uri template mechanism is that of an HTML form; and form processing rules call for sticking application/x-www-form-urlencoded values on the query string. So an HTML friendly spelling might look more like
GET /report?userid=123®ion=global
Of course, you can have "web form endpoints" that just redirect to the "real" target-uri, so it doesn't matter very much.
Basing on the naming conventions found here : https://restfulapi.net/resource-naming/ , I have a particular question to which I can not find an answer.
Taking the example of customers and accounts where sub-collection resource “accounts” of a particular “customer” can be identified using the URN “/customers/{customerId}/accounts” , how do I find accounts for multiple customer IDs? What are the naming conventions for such a case?
Is the only option to use filters? eg: customers/accounts?customerId=12,22
I tend to avoid filters and keep everything as a urn and keep the implementation of the backend system hidden. e.g. this
customers/accounts?customerId=12,22
means the client needs to know that customers are represented in the system by a variable called customerId. Clients shouldn't need to know that. They just need to know that customers have numbers, IMHO anyway.
This answer shows a solution for your situation, which would look like:
customers/accounts/12,22
although to keep it in line with the domain, where customers have ids and associated accounts, it would look like:
customers/12,22/accounts
and your backend framework would give you the list of customer 'numbers' from the url and at that point they become customerIds.
Not all frameworks may support arrays in paths but pick the right tool for the job and you can design your API to be elegant and a good match for your domain.
I am playing around with my own Parse server and would like to build a social media app just for fun. Just learning how to structure it and get everything developed.
One of the problems that I am having trouble wrapping my head around is how I would create a relationship structure between two users where the connection is mutual.
You would have to, on both ends, accept the relationship request.
I would also like to know how I would query for the friends list. Which would how would I query for the people the user has mutual connections with?
I hear that a friendship table relationship would be helpful for structuring a relationship with friends. But I would like to make it a mandatory mutual connection for people to be friends.
All you actually need is Request(person, friend) "PERSON asked to friend FRIEND", because requited and unrequited friendships can be extracted by query. You might prefer to keep those two relationships separately instead: Requited(person, friend) "PERSON asked to friend FRIEND and FRIEND asked to friend PERSON" & Unrequited(person, friend) "PERSON asked to friend FRIEND and FRIEND hasn't asked to friend PERSON". If a row (p, f) is in Requited then so is (f, p), and neither is in Unrequited. The two tables UNION to Request. But then you need to move rows between the tables when people friend or unfriend others. What is "best" logically depends on patterns of update & querying, and there will be likely be another "best" when implementation is included.
Database design is the identification of sufficient relationships/associations to describe any application situation. Each gets a table whose rows make a true statement from some characterizing statement template, aka predicate. Each query returns the rows that satisfy its own relationship/association, characterized by a predicate built from base predicates. Normalization helps with relationship/association/predicate/table choice, and so do information modeling methods. Pick a method (eg Object-Role Modeling) and learn it & how & why it leads to "good" designs while avoiding "bad" ones.
Create a new Object call "Relationships" and store both PFUser id's.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
So me and my boss aren't agreeing here and can't find any information on it. Scenario: I want to get all the users for a certain organisation. What should the URL be?
mydomain.com/users/by/organisation/{orgId}
OR
mydomain.com/organisation/{orgId}/users
Our arguments:
Case 1: The call is expected to return "users" and therefore the "resource" (first part of the call) should relate to it.
Case 2: The organisation "owns"/"is the parent of" the user and therefore the organisation should be first.
What are your thoughts?
UPDATE:
I am not to worried about what comes after the mydomain.com/{resource}. The question relates mostly to whether the HTTP action (GET, POST, PUT, DELETE) should relate to the first resource mydomain.com/users or whether it should reflect the relationship mydomain.com/organisations/users/.
You are probably aware that REST has no strict rules, you are more or less free to implement it however you like, but here are my 2 cents
mydomain.com/users/by/organisation/{orgId}
However this sounds like a good url because it sort of tells you what it does by reading it, this is not a great idea. Normally, each url segment specifies a resource that exists or can exist.
In this case, users represents one or more resources and so does organisation, but by does not, it's probably nothing more than a word to help clarify what the API does.
The call is expected to return "users" and therefore the "resource" (first part of the call) should relate to it.
A resource is not necessarily specified in the first part of the url. It can be the 2nd, 3rd or 10th if you want
mydomain.com/organisation/{orgId}/users
This looks much better but I think there is 1 point of improvement. You should rename organisation to organisations, to match users
This
mydomain.com/organisations/{orgId}
then gets the organisation with id orgId, and
mydomain.com/organisations/{orgId}/users
gets all the users that belong to that organisation.
To further narrow it down you could do
mydomain.com/organisations/{orgId}/users/{userId}
to get one specific user belonging to one specific organisation
UPDATE: I am not to worried about what comes after the
mydomain.com/{resource}. The question relates mostly to whether the
HTTP action (GET, POST, PUT, DELETE) should relate to the first
resource mydomain.com/users or whether it should reflect the
relationship mydomain.com/organisations/users/.
To answer your update:
I already mentioned it above; A resource is not necessarily specified in the first part of the url.. If the quality of the url improves by shifting the wanted resource to the back of the url, go ahead and do so
There is a conceptual difference between what you are trying to show here. The first is a filtering of all the user resources in the system based on some criteria. The second is showing the user resources that belong to an organisation.
The second url is ok for showing users that belong to an organisation I think.
The first url is effectively filtering the users that you want to see from all users.
Using the url might be ok for the filtering, though using url querystring is also be ok. so
mydomain.com/users?organisationId={orgId}
might be preferable. The urls can still contain querystrings and be restful.
Does it really make any sense to DELETE mydomain.com/users/organisation/{orgid}? Would you expect that to delete the organisation? if not then this isn't really pointing at a resource and so you are doing a search, and should probably use querystrings.
There are other options for doing the search like making the search criteria a first class object, or using one of the other filtering techniques in this question or this question
Let me start with this: technically, it shouldn't really matter. REST states that URL's must be discoverable through links, like links in normal (HTML) web pages.
However, a consistent, self-explanatory URL-structure won't harm at all. I'd suggest a hierarchical structure in URLs:
/organisations returns a list of all organisations
/organisations/123 returns a specific organisation (#123)
/organisations/123/users returns a list of users that are associated to that organisation
etc.
An alternative would be using a query string for filtering:
/users returns a list of all users
/users?organisation=123 returns a list of users that are associated to that organisation
From this hierarchical perspective, /users/by/organisation/123 wouldn't make much sense. What would be the result of calling /users/by/organisation? Or /users/by?
mydomain.com/users/by/organisation/{orgId}
What does "by" mean? That has no relationship to anything. Try to keep random words out of the URL.
Case 1: The call is expected to return "users" and therefore the "resource" (first part of the call) should relate to it.
That is not a rule that RESTful APIs enforce or expect. It is really not that common in the industry either, and I have worked with a LOOOT of APIs. Consider it to be a folder.
/users - a list of users
/users/1 - user with an ID of 1
/users/1/organizations - the orgs that user belongs to
/organizations - a list of orgs
/organizations/1 - Organization number 1
/organizations/1/users - The users for that organization
You are look at it like a programmer, like it is SOAP or a PHP function, trying to make getUsersByOrganization($orgId) and that is not how REST works. :)
IF you have to stick to case 1 (first URI segment = return type) then do this:
/users?orgId=1
That is perfectly RESTful and it is essentially just a filter. You could even do both, but I wouldn't. It is a relationship which has no place there. I try and keep filters to things like: ?active=true
The second is better. Walking down the URI should narrow the request, either as filters or showing parent-child objects. Users belong to an organization, so it should be organization/users. But I'd get rid of the "organization" level of the URI too if possible.
mydomain.com/{orgId}/users
By REST the URI structure does matter only from human perspective. It does not matter from the perspective of the REST client, because it is following link annotated with semantics.
To answer your question, it matter what do you want to describe, relationships or users. If you want to add and remove relationships, then you have to define a relationship collection. If you want to add and remove users, then you have to define an user collection. This matters only by manipulation. By GET you can define any kind of query which returns a bunch of users...
I'm trying to wrap my head around CQRS. I'm drawing from the code example provided here. Please be gentle I'm very new to this pattern.
I'm looking at a logon scenario. I like this scenario because it's not really demonstrated in any examples i've read. In this case I do not know what the aggregate id of the user is or even if there is one as all I start with is a username and password.
In the fohjin example events are always fired from the domain (if needed) and the command handler calls some method on the domain. However if a user logon is invalid I have no domain to call anything on. Also most, if not all of the base Command/Event classes defined in the fohjin project pass around an aggregate id.
In the case of the event LogonFailure I may want to update a LogonAudit report.
So my question is: how to handle commands that do not resolve to a particular aggregate? How would that flow?
public void Execute(UserLogonCommand command)
{
var user = null;//user looked up by username somehow, should i query the report database to resolve the username to an id?
if (user == null || user.Password != command.Password)
;//What to do here? I want to raise an event somehow that doesn't target a specific user
else
user.LogonSuccessful();
}
You should take into account that it most cases CQRS and DDD is suitable just for some parts of the system. It is very uncommon to model entire system with CQRS concepts - it fits best to the parts with complex business domain and I wouldn't call logging user in a particularly complex business scenario. In fact, in most cases it's not business-related at all. The actual business domain starts when user is already identified.
Another thing to remember is that due to eventual consistency it is extremely beneficial to check as much as we can using only query-side, without event creating any commands/events.
Assuming however, that the information about successful / failed user log-ins is meaningful I'd model your scenario with following steps
User provides name and password
Name/password is validated against some kind of query database
When provided credentials are valid RegisterValidUserCommand(userId) is executed which results in proper event
If provided credentials are not valid
RegisterInvalidCredentialsCommand(providedUserName) is executed which results in proper event
The point is that checking user credentials is not necessarily part of business domain.
That said, there is another related concept, in which not every command or event needs to be business - related, thus it is possible to handle events that don't need aggregates to be loaded.
For example you want to change data that is informational-only and in no way affects business concepts of your system, like information about person's sex (once again, assuming that it has no business meaning).
In that case when you handle SetPersonSexCommand there's actually no need to load aggregate as that information doesn't even have to be located on entities, instead you create PersonSexSetEvent, register it, and publish so the query side could project it to the screen/raport.