In order to build a Google Assistant app, Google provides two different APIs as part of their node.js actions-on-google library :
ActionsSdkApp
DialogflowApp
There have a common interface, but I don't understand what the difference is between the two and why I would use one or the other.
In short, these two objects provide similar (although not identical) methods to handle requests and provide results for two default ways Google allows you to build an Action for the Assistant.
The DialogflowApp object is the one you will likely use for most purposes. It is meant to work with the Dialogflow tool, letting it handle the Natural Language Processing (NLP) components and passing the results, where appropriate, to your webhook. It provides a few methods that are specific to Dialogflow features, such as Contexts, and maps other things to the response format that Dialogflow expects.
The ActionsSdkApp is meant to be used if you are using your own NLP and your webhook is getting things directly from Google (without using Dialogflow). If you need to build an actions.json file, you're using the Actions SDK.
Both have common methods and idioms, such as app.ask() and app.tell() and mapping app.data to session storage and so forth, even if the details of implementing these are different for each type.
You should be using the one that matches the tool that you're using. For most new users - that will likely be Dialogflow and the DialogflowApp object.
Update
Note that the API in the question, the specific objects asked about, and the specific methods talked about in my answer are for the previous version of the library.
The concept of when to use the ActionSDK vs Dialogflow objects in the current library still hold, so the concept behind this question and answer are still valid, but the technical details have changed.
Update - Jun 2020
The library in question is now deprecated, since it no longer works with the current version of Actions on Google (Actions Builder/SDK AoG v3). It still works with Dialogflow (which uses AoG v2) and if you're still using the AoG v2 Actions SDK.
IN SIMPLE TERMS
Use the Actions SDK for one-shot apps. These are apps that provide the required answer directly after being invoked and then stop. They give you just this one result. A typical example would be setting a timer to ten minutes.
Use the Dialogflow for all other apps, for those that are really conversational, where there are multiple paths to follow and where you want your user to provide more information during the conversation.
Related
I am currently developing an enterprise software. The client stated the need to translate certain texts that we gather from different sources into their home language, or at least into English. Due to GDPR concerns we cannot use external APIs like Google Translate API or DeepL. We need to have either a self-hosted solution or even better, just a python framework that contains translation logic for different languages internally.
Do you know of any such framework?
LibreTranslate seems to be a good option that we will be trying out.
I am currently evaluating the framework "wolkenkit" [1] for using it in an application. Within this application I will have a user interface for tenant-based data management. Only authenticated users will have access to this application.
Additionally there should be a public REST API following common standards and being callable by public (tenant security done with submission of a tenant-based API Key within the request headers).
As far as I have found out, the wolkenkit REST API does not seem to fit these standards in forms of HTTP verbs.
But as wolkenkit at all appears to me as a really flexible and easy-to-use framework, I wonder how to basically implement such a public API.
May it be e.g. a valid approach to create an own web application which internally connects to the wolkenkit backend? What about the additional performance overhead then?
[1] https://www.wolkenkit.io/
In addition to the answer of mattwagl, I would like to point out a few things that you may be interested in.
First of all, since wolkenkit is based on CQRS, the application has a separate API for writing and reading. That means, that if you send a command (whose intent is to change state) this goes to the write API. If you subscribe for events or run a query, this goes to the read API.
This again means, that if you send a command, it's up to the write side to respond to it. As the write side is not meant to return application state, all it says is basically: "Thanks, I have received the command." To get the actual result you have to wait for the appropriate event, which means subscribing to the read API.
In the wolkenkit documentation there is a nice diagram which shows this in a clear way:
If you now add a separate REST API (which actually fulfills the requirements of REST), this means that you need to handle waiting for the result internally. In other words: Clients in wolkenkit are always meant to be asynchronous, REST is not. Hence it's your job to handle the asynchronous behavior of the wolkenkit APIs in your REST API. I think that this is the hardest part.
Once you have done this, you will have a synchronous REST API, and of course it will have some overhead. But I think that since its overhead is limited to passing through and translating network requests, it should be negligible.
Oh, and finally, there is another thing that you have to watch out for: Since REST as it was meant originally relies on the HTTP verbs to transport semantics, you need to map GET / POST / PUT / DELETE to the semantic commands of wolkenkit. As long as this can be done 1:1, everything's fine – problems start when there are multiple commands that (technically speaking) do an UPDATE.
PS: I'm also one of the developers of wolkenkit.
PPS: However you are going to solve this, I would be highly interested to hear from you! It would be very great if you could share your experiences with us, as you are most probably not the last one with this idea. If you want to contact us, the easiest way would be via Slack.
wolkenkit applications can be accessed using an HTTP- and a Websocket-API. These APIs are both provided by the tailwind module that wolkenkit uses under the hood. In the tailwind repo you can find a very simple documentation of the available HTTP routes.
You're right, the wolkenkit HTTP-API is not a classic REST-API. It's more RPC-style which in our experience is a good fit for applications. There are only 3 routes that your clients/tenants need to support: /v1/command (POST) is used for issuing commands. The commands you post should follow the command schema. /v1/events (POST) can be used for streaming events to clients. These events will follow the event schema. Finally you have /v1/read/:modelType/:modelName (POST) to read models. You can simply use HTTPie to test these routes.
Authentication of these APIs is currently done using OpenID-Connect. There's a very detailed article on how to setup authentication using Auth0. I'm not quite sure if this fits your use-case but you could basically use any Authentication Service that follows this standard or that is able to issue JWT tokens.
Finally you could also build your own JavaScript client-SDK that runs inside browsers by building a module that uses the wolkenkit-client-js under the hood. This SDK can just use the same API as any other client to connect to your application.
Hope this helps.
PS: Please note that I am one of the authors of wolkenkit.
Following the Book App example in play 2 for scala, I now have a basic working app.
What I want now is to add some features like
User registration
User authenetication to access some pages
What is the best way to do it in play for scala? Should I manage it by my own? is there a plugin for that?
Note: I'm the maintainer of Silhouette.
I can suggest you Silhouette which is a core only fork of Secure Social with the intention to built a more customizable, non-blocking and well tested implementation.
For the first stable version there are only two open issues which must be resolved. And these issues are only future requests. There are no API changes planed. The documentation must be improved and a sample application is started. The unit tests are also a good starting point.
If you plan to follow the authentication flow as stated by Secure Social then stick with it. It exists since more than two years and it is well tested by many companies. Otherwise take a look at Silhouette.
You have two options:
Secure Social (http://securesocial.ws/)
But it has unusual registration flow, where the user have to enter your email first, and receive link to registration form.
However, there is a pull request that address this issue (https://github.com/jaliss/securesocial/pull/260)
Play Authenticate
It doesn't support Scala out of the box. But there is a workaround created by me here: https://github.com/joscha/play-authenticate/issues/92
Both of them requires you to write the interface layer to database. An important drawback in both of them, is that you won't be able to make use of reactive database drivers like Reactive Mongo. they assume that you will return the results immediately, not a Future of the result.
There is a securesocial plugin (http://securesocial.ws). Covers most common authentication methods, has registration stuff. I found it very usefull.
The drawback is it's documentation. If you want to do something a bit differ from the simplest scenarios - be prepared to read through the source code.
I have to create a project in iPhone which uses the Tin Can API. The Tin Can API is an advanced distributed learning process.
I have no idea about where to start in Objective-C.
I have read the site http://tincanapi.com.
For implementation, I have some basic questions:
How and to create my own LRS?
How Tin Can API can communicate with my own LRS and LMS with ASIHTTPRequest programatically?
There are two parts to TinCanAPI at play here. I'm suspecting you only need to handle one of them on iPhone. One part is the client-side that sends the statement date to the second part (the LRS server-side). It would be very odd to create the LRS server part on an iOS device, so I'm going with the thought that you need to send TinCan statements from an iOS device to an existing LRS.
An LRS accepts statement data via a REST interface and this data can be POSTed using a standard NSURLConnection or using AFNetworking. There are a couple of options for abstracting all those calls with a library one of which is a new OSS version of the basics appearing very soon from Rustici Software found here http://rusticisoftware.github.io/TinCanObjC/. There is no link for it just yet, but feel free to contact me for more details and I'll update this answer with the link as soon as there is a public link.
For your specific questions:
1.) You can create your own LRS by understanding the spec document and creating the REST endpoints as specified. This is not a trivial undertaking by any means.
2.) Your best bet is to use an SDK or simple GET and PUT/POST statements from AFNetworking to the TCAPI endpoint.
For a SaaS startup I'm involved in, I am building both a RESTful web API and a couple of client apps on different platforms that consume it. I think I've got the API figured out, but now I'm turning to the clients. As I've been reading about REST, I see that a key part of REST is discovery, but there seems to be a lot of debate between two different interpretations of what discovery really means:
Developer discovery: The developer hard-codes copious amounts of API details into the client, such as resource URI's, query parameters, supported HTTP methods, and other details that they've discovered through browsing the docs and experimenting with the API's responses. This type of discovery IMHO necessitates cool linkage and the API versioning question, and leads to hard coupling of the client code to the API. Not much better than if using a well-documented collection of RPC's it seems.
Runtime discovery - The client app itself is able to figure out everything it needs with little or no out-of-band information (presumably, only a knowledge of the media types the API deals with.) Links can be hot. But to make the API very efficient, a lot of link templating for query parameters seems to be needed, which makes out-of-band info creep back in. There are possibly other difficulties I haven't thought of yet since I haven't gotten to that point in development. But I do like the idea of loose coupling.
Runtime discovery seems to be the holy grail of REST, but I'm seeing precious little discussion about how to implement such a client. Almost all REST sources I've found seem to assume Developer discovery. Anyone know of some Runtime discovery resources? Best practices? Examples or libraries with real code? I'm working in PHP (Zend Framework) for one client. Objective-C (iOS) for the other.
Is Runtime discovery a realistic goal, given the present set of tools and knowledge in the developer community? I can write my client to treat all of the URI's in an opaque manner, but how to do this most efficiently is a question, especially over low-bandwidth connections. Anyway, URI's are only part of the equation. What about link templating in the Runtime context? How about communicating what methods are supported, aside from making a lot of OPTIONS requests?
This is definitely a tough nut to crack. At Google, we've implemented our Discovery Service that all our new APIs are built against. The TL;DR version is we generate a JSON Schema-like spec that our clients can parse - many of them dynamically.
That results means easier SDK upgrades for the developer and easy/better maintenance for us.
By no means the perfect solution, but many of our devs seem to like.
See link for more details (and make sure to watch the vid.)
Fascinating. What you are describing is basically the HATEOAS principle. What is HATEOAS you ask? Read this: http://en.wikipedia.org/wiki/HATEOAS
In layman's terms, HATEOAS means link following. This approach decouples your client from specific URL's and gives you the flexibility to change your API without breaking anyone.
You did your home work and you got to the heart of it: runtime discovery is holy grail. Don't chase it.
UDDI tells a poignant story of runtime discovery: http://en.wikipedia.org/wiki/Universal_Description_Discovery_and_Integration
One of the requirements that should be satisfied before you can call an API 'RESTful' is that it should be possible to write a generic client application on top of that API. With the generic client, a user should be able to access all the API's functionality. A generic client is a client application that does not assume that any resource has a specific structure beyond the structure that is defined by the media type. For example, a web browser is a generic client that knows how to interpret HTML, including HTML forms etc.
Now, suppose we have a HTTP/JSON API for a web shop and we want to build a HTML/CSS/JavaScript client that gives our customers an excellent user experience. Would it be a realistic option to let that client be a generic client application? No. We want to provide a specific look-and-feel for every specific data element and every specific application state. We don't want to include all knowledge about these presentation-specifics in the API, on the contrary, the client should define the look and feel and the API should only carry the data. This implies that the client has hard-coded coupling of specific resource elements to specific layouts and user interactions.
Is this the end of HATEOAS and thus the end of REST? Yes and no.
Yes, because if we hard-code knowledge about the API into the client, we loose the benefit of HATEOAS: server-side changes may break the client.
No, for two reasons:
Being "RESTful" is a property of the API, not of the client. As long as it is possible, in theory, to build a generic client that offers all capabilities of the API, the API can be called RESTful. The fact that clients don't obey the rules, is not the API's fault. The fact that a generic client would have a lousy user experience is not an issue. Why is it important to know that it is possible to have a generic client, if we don't actually have that generic client? This brings me to the second reason:
A RESTful API offers clients the option to choose how generic they want to be, i.e. how resilient to server-side changes they want to be. Clients which need to provide a great user experience may still be resilient to URI changes, to changes in default values and more. Clients doing batch jobs without user interaction may be resilient to other kinds of changes.
If you are interested in practical examples, checkout my JAREST paper. The last section is about HATEOAS. You will see that with JAREST, even highly interactive and visually attractive clients can be quite resilient to server-side changes, though not 100%.
I think the important point about HATEOAS is not that it is some holy grail client-side, but that it isolates the client from URI changes - it is assumed you are using known (or developer discovered custom) Link Relations that will allow the system to know which link for an object is the editable form. The important point is to use a media type that is hypermedia aware (e.g. HTML, XHTML, etc).
You write:
To make the API very efficient, a lot of link templating for query parameters seems to be needed, which makes out-of-band info creep back in.
If that link template is supplied in the previous request, then there is no out-of-band information. For example a HTML search form uses link templating (/search?q=%#) to generate a URL (/search?q=hateoas), but nothing is known by the client (the web browser) other than how to use HTML forms and GET.