I need a help about distinguish similar entities.
In my case I have one entity called '#agent' with some entries, two of them is 'Iago Campos' and 'Iago Coutinho'. I have an intent called 'transfer' that is triggered when user says that want to talk to someone. When user says 'I want to talk with Iago' dialogflow doesn't match any of the 'Iago'
I want to know if it's possible to make dialogflow ask to user if he wants to talk with Iago Campos or Iago Coutinho. I was looking aboult Fulfillment, but for many reasons I'm not confortable using webhook to just distinguish agents...
#Agents entries
Dialog Flow doesn't match any of the “lago” because it does not know what decision it has to take since it found 2 matches “lago Campos” and “lago Coutinho”.
If you proceed to say “Campos” dialog flow will find only one match “lago campos” and it will return it. It would be ideal to remove the world “lago” since it causes redundancy in your system.
On the other hand a fast solution would be to create another Intent specifically for when the user enters the word “lago” and that it is linked with a trigger that replies what “Lago” is it referring to. Here the final user can choose one “lago” or another.
So here I could suggest creating this behavior using a Fulfillment webhook in that way you can use it from the same intent
Related
I have a question about tracking activity and where it belongs.
With a lot of my domain commands, you also might want to track the activity and modifications made by users to a particular context or object.
For example:
lets say we have a items domain/context where we can create and edit items. Users are going to make requests to the api to do this. We might want to track who created an item and an modifications made to it.
In a typical CRUD model, you'd probably find the created by field in the domain object/table
Something doesn't feel right when using DDD to have the activity in the domain object. The activity log feels like a general service that would cross many boundaries? Is it right to have the activity log of who changed what in the domain object. It would feel quite clean and focused without it. The activity logging seems specific to the applications case, not the domain?
So:
Should the activity tracking be in the domain object?
If it shouldn't how do you go about handling this in one command/request. I keep hearing people saying about you should only touch 1 boundary in a command/request.
I would think of this activity log as any other piece of data. You would put it together with the business logic around it. Why do you need this information in the first place? Is your items context going to implement business logic that needs the activity log? If not, then I'd say it doesn't belong in that context.
If what you are trying to achieve with this log is some data analysis that needs the activity from several contexts, then I would say publish events from your business operations (every time a user does something with one of the contexts) and have your activity tracking context listen to them and store the activity in a way that serves this purpose.
If, instead, your items context needs to apply some sort of logic, based on the past activity, then keep it in that context in a format that allows you to implement this business logic.
It's also possible that you actually need both. Some context might just publish the events and not store the activity, while others will publish the events and also track the activity for their own internal needs.
I would like to know about authorization in jUDDI. I would like to give Publisher capabilities to few of my clients And also I want few of my clients to inquire or access only those services which are related to them. I want to hide the rest of the services which are not related to them. Can we achieve this using jUDDI? and How?
As of right now, no. There is an open ticket for this to provide role, group, list, etc access control on a per record (business/service) basis but it hasn't been implemented.
This problem is also a complex one, since UDDI has both a search and a getDetails set of methods. Get Details in the easy one, but search is very complex. Filtering out records and keeping the paging option still functional would be a challenge
In an ideal RESTful API that supports multiple accounts, should each resource have it's unique identifier across the entire system, or it is OK if that identifier is unique for the specific account that it belongs to.
Are there any pros and cons for each scenario?
To give an example.
Would this be fine from the REST principles?
http://api.example.com/account/1/users/1
...
http://api.example.com/account/50/users/1
or would this approach be recommended?
http://api.example.com/account/1/users/{UNIQUE_IDENTIFIER}
...
http://api.example.com/account/50/users/{ANOTHER_UNIQUE_IDENTIFIER}
You reveal valid user numbers by always having the first user as 1. Someone then knows that any account will also have a user 1. I'm not saying that you should hide user IDs just through obscurity but why make it easy for someone to find the user IDs in another account?
All that really matters is that each resource has a unique identifier. Both of your examples accomplish that, so you seem to be okay (RESTfully speaking)
I don't see any compelling reason to use one over the other. I'd choose whatever makes more sense for your implementation.
Since, from the perspective of an external system using your REST API, the entire address should be considered to be the "identifier" for that resource object, so your first example is fine.
For example,
I want to separate the online shop into three parts.
User: the user related information, for example, they login. logout.
Communication: sending email, or newsletter modules.
ShoppingCart: displaying order.
Ok, these three module is the main function of of my little online store.
Clearly, the user medule, deal with its own stuff, for example, user change their profile pic(ok, I think it is non-sense to have a profile pic for user, just think it is an example.)
user ---call---> user
But I got a problem here, is when the user doing some functions, which require cross-module call....
Let me give a example, if the user lost the password, the user needs to use the communication method to send a new password to him/her...The situation will become somethings like that:
user ----call---> communication
A worse situation is use all the modules, here is the situation:
The user using a shopping chart to deal with his/her shopping, after that, he /she make the order, and a invoice use communication modules to send to the user.
user ----call---> shoppingCart ---call---> Communication
Therefore, each module is not separate, all modules knows each others.... But I don't want to do that, for example, this time I am doing a new application, for example, I doing a video sharing web site which only use "user" and "communication", I don't really need the "shoppingChart. ", and having a new video module.....
It is ok for me "upgrade" my user and communication method to deal with the video module, but the question is, if I got something bugs fix, for example, the getFullName method is doing something wrong, when I need to "upgrade" back the online shop application, I need to take the "video" module too.....
What I wanna to ask is, how to separate their responsibility, and how to make the code more reusable? Thank you.
It is good practice to minimize the coupling in your application, but removing it entirely is not always possible.
My recommendation would be to build base classes User, Communication, and ShoppingCart that provide only basic interfaces, such as getFullName()
Then, for each application, write separate wrappers that are able to interact with your base classes. You may have an OnlineShopping class and a VideoSharing class, that contain the functions you need that are specific for each application.
There are a number of structural patterns that may help you out with your design. Also, take advantage of inheritance for functionality that is similar across all applications.
Currently I am developing an API and within that API I want the signed in users to be able to like/unlike or favorite/unfavorite two resources.
My "Like" model (it's a Ruby on Rails 3 application) is polymorphic and belongs to two different resources:
/api/v1/resource-a/:id/likes
and
/api/v1/resource-a/:resource_a_id/resource-b/:id/likes
The thing is: I am in doubt what way to choose to make my resources as RESTful as possible. I already tried the next two ways to implement like/unlike structure in my URL's:
Case A: (like/unlike being the member of the "resource")
PUT /api/v1/resource/:id/like maps to Api::V1::ResourceController#like
PUT /api/v1/resource/:id/unlike maps to Api::V1::ResourceController#unlike
and case B: ("likes" is a resource on it's own)
POST /api/v1/resource/:id/likes maps to Api::V1::LikesController#create
DELETE /api/v1/resource/:id/likes maps to Api::V1::LikesController#destroy
In both cases I already have a user session, so I don't have to mention the id of the corresponding "like"-record when deleting/"unliking".
I would like to know how you guys have implemented such cases!
Update April 15th, 2011: With "session" I mean HTTP Basic Authentication header being sent with each request and providing encrypted username:password combination.
I think the fact that you're maintaining application state on the server (user session that contains the user id) is one of the problems here. It's making this a lot more difficult than it needs to be and it's breaking a REST's statelessness constraint.
In Case A, you've given URIs to operations, which again is not RESTful. URIs identify resources and state transitions should be performed using a uniform interface that is common to all resources. I think Case B is a lot better in this respect.
So, with these two things in mind, I'd propose something like:
PUT /api/v1/resource/:id/likes/:userid
DELETE /api/v1/resource/:id/likes/:userid
We also have the added benefit that a user can only register one 'Like' (they can repeat that 'Like' as many times as they like, and since the PUT is idempotent it has the same result no matter how many times it's performed). DELETE is also idempotent, so if an 'Unlike' operation is repeated many times for some reason then the system remains in a consistent state. Of course you can implement POST in this way, but if we use PUT and DELETE we can see that the rules associated with these verbs seem to fit our use-case really well.
I can also imagine another useful request:
GET /api/v1/resource/:id/likes/:userid
That would return details of a 'Like', such as the date it was made or the ordinal (i.e. 'This was the 50th like!').
case B is better, and here have a good sample from GitHub API.
Star a repo
PUT /user/starred/:owner/:repo
Unstar a repo
DELETE /user/starred/:owner/:repo
You are in effect defining a "like" resource, a fact that a user resource likes some other resource in your system. So in REST, you'll need to pick a resource name scheme that uniquely identifies this fact. I'd suggest (using songs as the example):
/like/user/{user-id}/song/{song-id}
Then PUT establishes a liking, and DELETE removes it. GET of course finds out if someone likes a particular song. And you could define GET /like/user/{user-id} to see a list of the songs a particular user likes, and GET /like/song/{song-id} to see a list of the users who like a particular song.
If you assume the user name is established by the existing session, as #joelittlejohn points out, and is not part of the like resource name, then you're violating REST's statelessness constraint and you lose some very important advantages. For instance, a user can only get their own likes, not their friends' likes. Also, it breaks HTTP caching, because one user's likes are indistinguishable from another's.