How do you create a document in Google Docs programmatically? - api

The documentation for Google Documents List API, seems to say that you can create a local document and upload it. Is there no way to actually create and edit a document on Google Docs through an API?

While the docs call it "uploading", everything boils down to sending an appropriately formatted HTTP POST request, so of course it can actually be a new creation rather than an actual "upload" of an otherwise existing file. (Creation through POST requests is similar to what's normally described as a REST API, though in real REST you'd typically use a PUT request instead of course).
You just need to create a blob of data representing your document in any of the formats listed here -- depending on your programming language, simplest may be text/csv for a spreadsheet and application/rtf for a text-document -- then put in in an appropriately formatted POST data. For example, to make a spreadsheet in the simplest way (no metadata), you could POST something like:
POST /feeds/default/private/full HTTP/1.1
Host: docs.google.com
GData-Version: 3.0
Authorization: <your authorization header here>
Content-Length: 81047
Content-Type: text/csv
Slug: Example Spreadsheet
ColumnA, ColumnB
23, 45
Each specific programming language for which a dedicated API is supplied may offer help with this not-so-hard task; for example, in Python, per the docs, the API recommends using ETags to avoid overwriting changes when multiple clients are simultaneously "uploading" (i.e., creating or updating docs). But preparing the POST directly is always possible, since the almost-REST API is documented as the protocol underlying all language-specific APIs.

Alex's answer, while undoubtedly correct, begs the question: "how do I do that via the Google Docs API?"
Here's a way (in Python, 'cause I'm that kind of guy):
import gdata.docs.service
import StringIO
client = gdata.docs.service.DocsService()
client.ClientLogin(username, password,
source='Spreadsheet Creation Example')
content = 'COL_A, COL_B, COL_C, COL_D\ndata1, data2, data3, data4'
ms = gdata.MediaSource(file_handle=StringIO.StringIO(content),
content_type='text/csv',
content_length=len(content))
entry = client.Upload(ms, 'Test Spreadsheet')
This is a small mashup of techniques that I found in http://code.google.com/p/gdata-python-client/source/browse/tests/gdata_tests/docs/service_test.py , which I in turn found via this post from the Google Group for the GData Docs API.
The key insights (for me anyway) were:
realizing that the MediaSource constructor's formal parameter "file_handle" will take any file-like object, and
discovering (as the OP's followup to the Google Group post mentions) that the unit tests are a great source of examples
(I wasn't able to find the Python-specific developer's guide referenced by Alex's doc link -- possibly it's been lost or buried in Google's move of documentation assets from code.google.com to developers.google.com. Alex's link now redirects to the more generic document that shows mostly .NET and Java examples, but only a little Python.)

As of Feb 4, 2019, Google Docs now has a REST API.
See documentation:
https://developers.google.com/docs/api/

(Sep 2019) There are 3 ways to create a document in Google Docs programmatically:
Google Docs REST API (low-level; Python, JS/Node.js, Java, C#/.NET, PHP, Ruby, Go, etc.)
Google Apps Script (high-level; JavaScript-only)
Google Drive API (low-level like Docs API above; both alternatives above can create or edit documents, but this one is create- or delete-only plus editing sharing/permissions)
The Docs API was officially launched in Feb 2019. I produced a high-level video overview of what a mail merge application using the API would look like. (It's not a full-fledged G Suite Dev Show episode but does link to a working sample.) Check out the various guides on using the API, including Quickstart examples in a variety of programming languages.
OTOH, Apps Script is a simpler, higher-level alternative. It's a custom server-side JavaScript runtime supporting apps that are hosted+executed in Google's cloud. Use objects to talk to various Google APIs (G Suite & beyond) without knowledge of HTTP, REST, nor OAuth2. You can also access external databases with its JDBC Service or call other apps via its URL Fetch Service.
With Apps Script, you can create standalone applications, document-bound applications (only works for a single document), or Google Docs Add-ons to extend the functionality of Google Docs. Here are the Google Docs Apps Script overview page as well as the Apps Script reference documentation for Google Docs (Document Service). I've also produced a variety of Apps Script videos if that's your preferred learning vehicle. If you're new to Apps Script, see my answer to a similar SO question for more learning resources.
Typically the Docs, Sheets, Slides, etc., APIs are used to perform document-oriented functionality while the Drive API is used primarily for file-based operations. However "create" is a special case where you can use either. See my answer to another SO question which shows the difference b/w creating a new Google Sheet via the Sheets API vs. the Drive API. (Both samples in Python.) Read this if you're interested in managing sharing or updating permissions of Google Docs.

Related

How can you document a REST API usage/consumption?

We have a medium size app (100+ SQL tables), and we often need to integrate it with partner APIs (with our system as a client/consumer). Process of designing such integration is non-trivial:
We often need to map columns in our database to fields in requests to partner API.
Some fields in requests to partner API must be constant, or conditional
In rare occasions output from one API response becomes an input to another API request
There are many resources on the web to document REST APIs - there are specific formats for that (Swagger, RAML, etc.). These formats allow efficient generation of client code and human-readable documentation. However these formats are not very helpful for describing how your app integrates with an API. We create lengthy Microsoft Word documents which contain more or less a copy of partner API methods with comments how every individual field should be used. Such solution seems sub-optimal.
Googling for better options did not yield many results, namely Swaggerhub seems to have "comments" functionality which seems to target the problem above and pretty much that's all.
Question: are there some tools, formats, workflows, ideas, etc. which facilitate designing and documenting API integrations described above?
I dont know which language you use, but i work with ApiDoc
https://apidocjs.com/
He is perfect to generate an API REST doc with comment in NodeJS, he can be used with many language

How to call Google NLP Api from a Google Chrome extension

My aim is to select some text from a web page, start a google chrome extension and give the text to a google cloud api (Natural Language API) in my case.
I want to do some sentimental analysis and then get back the result to mark/ highlight positive sentences in green and negative ones in red.
I am new to this and do not know how to start.
The extension consists of manifest, popup etc. How should I call an API from there that does Natural Language Processing?
Should I create a Google Cloud Application with an API_KEY to call? In that case I would have to upload my credentials right?
Sorry sounds a bit confusing I know but I just don't know how I can bring this 2 things together an would be more than happy about any help
The best way to authenticate your app will depend on the specific needs and use cases of your application. You can see an overview of all the different methods here.
If you are not planning on identifying users nor on using a back end server that handles authenticating (as I assume to be your case), the best option would indeed be to use API keys. They do not identify the user, but are enough for the Natural Language APIs.
To do this you will need to create an API key for the services you want and add the necessary restrictions to make the key as secure as possible. Detailed instructions on how to do this and how to use the key in a url can be found here.
The API call could be made from within the Chrome extension with any JavaScript method capable of performing POST requests. For example using XMLHttpRequest or the Fetch API. You can find an example of the parameters that need to be included in the request here.
You may run into CORS issues when making the request directly from the extension. I recommend reading this answer, where a couple of workarounds for these issues are suggested.

Can you create Google Forms from Google Docs in an application?

I am thinking about app that will use google form and I need to create forms from that app. Is there a way how can I create form in google docs without using website but through some api or some other way?
I can offer an idea for a solution using Google App Script.
Since the beginning of 2013 you can create new forms using the App Script Forms Service API quite easily.
var form = FormApp.create(title)
.setDescription(description)
.setConfirmationMessage('Thanks for responding!')
;
The problem now is how to get that App Script running from your non App Script code.
You can use App Script to create a Web App that reacts to HTTP GET requests.
So putting it together, you may be able to create an App Script Web App that reacts to a GET request and when it gets the right URL parameters, it creates the form.
(Nov 2020) Yes, it is possible to programmatically create Google Forms. You can do it with Google Apps Script using its Forms service. You can also extend the code to read in the contents from Google Docs (with Apps Script's Document service) and use it for the creation of Google Forms.
I created a Google Workspace (formerly G Suite) Add-on, which you can think of as a Google Docs extension, called GFormIt. Its original purpose was intended for teachers to write exams/quizzes, possibly with answers, in Google Docs, then automatically convert them to Google Forms to distribute to students who submit their answers into Google Sheets (the destination for Google Forms submissions).
Furthermore, if you (the teacher) provided answers to your test questions, GFormIt would also auto-submit your answers to the Sheet as if you were a student. If you do that, and use a tool like Flubaroo to grade the exam, you could designate your row in the Sheet as “the answer key.” You can learn more about how it works, including viewing a short video, at the GFormIt page linked above.
This Google Docs add-on, along with others for Google Docs, Sheets, Slides, Forms, etc., are all certified/validated by Google and available for free to anyone from the Google Workspace Marketplace. (However, your admins may have to grant permissions for you to try to install them to your corporate Workspace account.) If interested in building your own add-on, please see the developer documentation and perhaps some of my introductory videos to get started, the most relevant being the one linked to at the top of this answer.
Apps Script is a serverless Google technology, meaning you write your code (using JavaScript) in the browser, and it is hosted by & executed on Google servers. If you wanted to create your own web app (and hosted anywhere), you would have to wait for a Google Forms REST API which does not exist at the time of this writing. (If we ever launch one, you'll find its documentation at https://developers.google.com/forms along with the others like Sheets https://developers.google.com/sheets, Gmail https://developers.google.com/gmail, Drive https://developers.google.com/drive, etc.)
Earlier this year (Mar 2022) the new Google Forms Api graduated from Beta. It is more powerful that the previous versions and caters for two main use cases:
Automated form creation and editing: Enables automated form creation
and editing. Enables rapid form generation from large volume question
banks or other data backends.
Reaction to Form responses: The API also enables developers to build
automations for acting on incoming responses. Examples include
developing real-time dashboards or visualizations and triggering
business workflows based on response data.
We have used it to build an integration that Creates documents and slides each time a form is completed: www.portant.co/google-forms-to-docs and it works really well.
I think the other key use case looks like it would be a good fit for you and others looking for a solution like this.
Cheers, James
Sorry, the API doesn't support programmatically creating forms.

Is there any quick and easy way to upload a Google Doc from SAP?

We're creating a custom table in SAP comprising all of the information we need and the customer needs the report from this table uploaded to Google Docs. We do not use Business By Design. Is there any other quicka nd easy way to upload our report?
I don't know much about SAP but the Documents List API has methods to programmatically upload a document to Google Docs: https://developers.google.com/google-apps/documents-list/.
For instance, if you can export the SAP table as a csv file, that can be automatically converted into a Google Spreadsheet during the upload process.
You could also go with a no-programming required solution and install the Google Drive app on a machine with access to the files for automatic sync up to Google Drive:
http://support.google.com/drive/bin/answer.py?hl=en&answer=2374989
suggest you take a look at the SAP Developer Network (SDN) / SAP Community Network (SCN) where there is a project called ABAP2GAPPS that has done this.
Note the ABAP2GAPPS example is a bit difficult to figure out (but you can learn a lot from it), and it also uses the OAuth2 'authorization code flow" OAuth2.0 flow/pattern, which requires an end-user 'consent' in an browser pop-up...so if you want to push up a file from ABAP automatically from a background job without end-user interaction then ABAP2GAPPS is not the full answer (but again, ABAP2GAPPS is a great example, suggest you look at it.)
We recently were able to achieve an interface from SAP ABAP to the Google Fusion Table API using OAuth2, with only about a 100 lines of ABAP...and the techniques we employed could be used on any of the Google API's...here's a link to the video:
Link to YouTube video interface ABAP to Google API
hope you find this helpful

Google Docs publishing 'server'

You might be familiar with Google Docs' (and presumably also the other 'office' apps) ability to communicate with a blog server to publish a post directly from its interface. (It's located in Share > Publish as a web page).
I'm interested in knowing the standard for the data transmission that this system uses. Of course, I can always reverse-engineer the code for one of the blog applications supported, but a formal specification would be more useful.
Thanks in advance!
It seems to support three types of API :
Blogger API
MovableType API
and MetawebBlog API
Those (at the the two last ones) seem to be based upon some kind of XML-RPC protocol (see also) ; so, the ability to use them has to be linked to what API (classes/methods) they export -- for blogging-software, those will be methods to get/create posts, most probably ; and only a few methods, I guess, so that using those API is not too complicated...
The first one seems to use some kind of ATOM-based format (see, for instance, what has to be used to create a new post)
Still, using that kind of "half-standard" API means you'll have to code some stuff each time you want your application to support a new API ; happily, there are not that many blogging-software related APIs : many blogging software tend to use the same ones, which is great : it allows you (or google docs, btw ;-) ) to publish to many different kind of software with only implementing the 2 or 3 most important / most used APIs.
For instance, the well-know platform Wordpress supports both Metaweb, Blogger, and MovableType APIs -- even if those were created for other software, at first -- coincidence (or not ^^ ) those are the same as Google Docs supports : the most used, I suppose ;-)
Actually, the Blogger API that Google Docs uses is the original (depricated) XML-RPC one, not the new GData API. The original Blogger protocol is the oldest and the simplest of the three supported (good for a quick implementation).