When developing for Alexa, every skill has a unique Id. This allows me to develop multiple skills, using the same lambda / codebase, that return unique info based on the skill id.
However, from what I've seen with Google Assistant, Actions don't have ids. Requests include a unique userId and the conversationId. And Responses include an intent id -- but there's no way to identify the action itself.
Any ideas / pointers to things I may have missed?
There are a few ways you can approach this, depending on what platform you're using for your webhook.
For both Dialogflow and the Action SDK, you can always specify a unique query parameter as part of the webhook or even have different path portions of the webhook go to the same lambda and examine either the query value or the path. This has the benefit that you're in full control of what the possible values are.
If you're using Dialogflow, there is a unique IntentID for each Intent that comes through. This might be one way to track which one has been invoked. But this seems somewhat kludgy.
Also for Dialogflow, you can set unique headers in the Dialogflow console, and then examine the value of these headers in your webhook. Again, this has the advantage of giving you control of the value.
The Action SDK doesn't have that feature, but it does transmit a JWT token in the Authorization header. This token is for verifying it has come from the correct project (and from Google), but once you've decoded it (and verified it), the aud field should contain the same project ID as the project in the Action Console.
Related
I am developing an agent, and have an entity within the agent.
now what i need is to add some new details to the entity, but not by opening dialogflow.
I want to make a REST API to add it for me.
Is it possible?
It sounds like you're looking for the API to either create or patch entities.
From reading the docs, it doesn't look like this is possible via HTTP requests.
You could try automated expansion:
Automated expansion of developer entities allows an agent to recognize
values that have not been explicitly listed in the entity.
If a user's request includes an item that isn't listed in the entity,
automatic expansion recognizes the undefined item as a parameter in
the entity. The agent sees the user's request is similar to the
examples provided, so it can derive what the item is in the request.
For example, consider a shopping list with items to buy:
If a user says "I need to buy some vegetables", "vegetables" will be
picked up as a value, even though it's not included in the #item
entity. With automated expansion enabled, the agent sees the user's
query is similar to the training phrases provided in the intent and
can pick out what should be extracted as a new value.
The closer the user's input is to the examples provided in the
training phrases section, the better the results the automated
expansion feature provides. This is another reason to provide as many
examples as possible.
I use an authentication service Auth0 to allow users to log into my application. The application is a Q&A platform much like stackoverflow. I store a user profile on my server with information such as: 'about me', votes, preferences, etc.
When new user signs in i need to do 1 of 2 things:
For an existing user - retrieve the user profile from my api server
For a new user - create a new profile on the database
After the user signs in, Auth0(the authentication service) will send me some details(unique id, name and email) about the user but it does not indicate whether this is a new user(a sign up) or a existing user(a sign in).
This is not a complex problem but it would be good to understand best practice. I can think of 2 less than ideal ways to deal with this:
**Solution 1 - GET request **
Send a get request to api server passing the unique id
If a record is found return it
Else create new profile on db and return the new profile
This seems incorrect because the GET request should not be writing to the server.
**Solution 2 - One GET and a conditional POST request **
Send a get request to api server passing the unique id
The server checks the db and returns the profile or an error message
If the api server returns an error message send a post request to create a new profile
Else redirect to the home page
This seems inefficient because we need 2 requests to achieve a simple result.
Can anyone shed some light on what's best practice?
There's an extra option. You can use a rule in Auth0 to send a POST to the /users/create endpoint in your API server when it's the first time the user is logging in, assuming both the user database in Auth0 and in your app are up-to-date.
It would look something like this:
[...]
var loginCount = context.stats.loginsCount;
if (loginCount == 1) {
// send POST to your API and create the user
// most likely you'll want to await for response before moving on with the login flow
}
[...]
If, on the other hand, you're referring to proper API design and how to implement a find-or-create endpoint that's RESTful, maybe this answer is useful.
There seems to be a bit of disagreement on the best approach and some interesting subtleties as discussed in this post: REST Lazy Reference Create GET or POST?
Please read the entire post but I lean towards #Cormac Mulhall and #Blake Mitchell answers:
The client wants the current state of the resource from the server. It is not aware this might mean creating a resource and it does not care one jolt that this is the first time anyone has attempted to get this resource before, nor that the server has to create the resource on its end.
The following quote from The RESTful cookbook provided by #Blake Mitchell makes a subtle distinction which also supports Mulhall's view:
What are idempotent and/or safe methods?
Safe methods are HTTP methods that do not modify resources. For instance, using GET or HEAD on a resource URL, should NEVER change the resource. However, this is not completely true. It means: it won't change the resource representation. It is still possible, that safe methods do change things on a server or resource, but this should not reflect in a different representation.
Finally this key distinction is made in Section 9.1.1 of the HTTP specification:
Naturally, it is not possible to ensure that the server does not
generate side-effects as a result of performing a GET request; in
fact, some dynamic resources consider that a feature. The important
distinction here is that the user did not request the side-effects,
so therefore cannot be held accountable for them.
Going back to the initial question, the above seems to support Solution 1 which is to create the profile on the server if it does not already exist.
I have recently started testing rest based web services. I am wondering what are common issues faced while testing them.
I generally look for
response status (http code is among 200/400/500)
response headers (cache control, response type, content length )
if expected fields / values are present in json response.
I want to know what else to look for and issues in general while testing rest based web services
This is actually a very broad question but, here are the things that I look for while testing rest API's:
Response codes, Response headers
Check if Authentication/Authorization is correct based on user privileges
Check to see if the supplied value can break the output
Intentionally pass different Data-Type values to see if proper handling is done or not
Use load testing tools to see how many concurrent requests an API can handle
Again these are just a few things that will depend on the type of API you are building. Feel free to add more as you progress.
There are many, but let me share a few that aren't even specifically API issues but a full API integration test will help find it.
We did an integration API test where a publisher's product listing endpoint was hit, and then we randomly picked 100 of those products. Every few weeks we would find a bunch of bad product ID's. How was it possible? They would update the database but the product listing endpoint was cached and had bad information for hours until it was refreshed automatically.
Another time we found an e-commerce company in Brooklyn that, on average, had 3,500 products out of their 50k+ were missing a category. This meant 3,500 products not showing up if you browsed by categories, and potential lost sales.
We have a whole case study of this stuff on our website. Weird and unexpected stuff happens all the time. Test for everything and catch as much as you can. Every object in the payload should be verified, it may seem like overkill but there are platforms that can do all that work for you.
Here are suggestions based on my experience while testing Restful APIs.
Make sure that you are validating proprietary headers if you are using with your APIs.
Confirm that you are including correct location header in the response so that Rest API caller can use that for verification or for subsequent calls.
Check that location header protocol is correct i.e as per your design. (http/https). It's very important for subsequent calls.
I know how to get the list of organizations for a user.
However, I want to let the user type in the user/organization name and provide autocomplete for that name where the autocomplete includes all user/organizations, not just the organizations they belong to.
It would be too long to get the entire list (and I am not sure that GitHub even exposes that), but the top 5-20 for any given prefix is all I want.
The Search API smells more like a single transaction search and not an autocomplete API, so while I could use it, most likely it would hit the rate limit too often and give a bad UX.
There is something close to this with https://github.com/autocomplete/users?q=prefix, but that is not part of the official GitHub API, so I know that the back end does support these kind of queries... I am just not finding it from the API documentation, and I don't want to access a non-API URL.
GitHub does not do this for you and likely never will. One option you have is to construct a service like that yourself and constantly update your list of users. One way to update the list of users (sanely) is to do the following:
Make an initial GET to /users?per_page=100
Save the ETag header that's returned and use pagination to get all of the most recent ones
On future requests send along the ETag and when there are new users, save the newest ETag.
Repeat.
So you'll be able to then build an auto-completion service yourself so long as you keep your listing of GitHub users up-to-date.
Also note, that sending along the ETag will save your ratelimit if there is nothing new to return.
is there a way to fetch the venues search in iOS without the user entering his password or showing some foursquare oauth website?
I don't think that this oAuth makes any sense for this kind of request, it should be just an REST api like so "https://api.foursquare.com/v2/venues/search?ll=-27.58818,-48.523248&client_id=JN00ABQBOCK5V54FQ1TWQFLOOIDU12UAZXURHXGXNK0ESJBY&client_secret=14ES1NXTCL1XC5HSLBUT4LWE4ROEDGNYKKWGGERZQGUKQ5JC"
but this one is deprecated =/
Any thoughts?
It's not deprecated, you're just missing the "versioning" parameter that specifies what version of the API you're trying to use.
Requesting https://api.foursquare.com/v2/venues/search?ll=-27.58818,-48.523248&client_id=JN00ABQBOCK5V54FQ1TWQFLOOIDU12UAZXURHXGXNK0ESJBY&client_secret=14ES1NXTCL1XC5HSLBUT4LWE4ROEDGNYKKWGGERZQGUKQ5JC&v=20111107 will remove the warning you saw in your response
Add a query string parameter to your request as follows..
&v=20111119 // Choose a proper version.
Update: this is actually a date. So make sure you send current date in yyyymmdd format against v parameter.
According to FourSquare's docs page on venue searching an acting user is no longer necessary:
Some endpoints (e.g. venue search) allow you to not act as any
particular user. We will return unpersonalized data suitable for
generic use, and the performance should be slightly better. In these
cases, pass your client ID as client_id and your client secret as
client_secret. Although the draft 11 of the OAuth2 spec provides a
mechanism for consumers to act via token entitled Client Credentials,
we do not currently support this.