If it is possible, how would I achieve the following URL rewrites using PouchDB Server?
At /index.html, display the HTML output of /index/_design/index/_show/index.html.
At /my_database/index.html, display /my_database/_design/my_database/_show/index.html.
My aim is to use PouchDB (and eventually CouchDB) as a stand-alone web server.
I am struggling to translate the rewrite documentation into working code.
Apache CouchDB uses an HTTP API and (consequently) can be used as a static web server--similar to Nginx or Apache HTTPD, but with the added bonus that you can also use MapReduce views, replication, and the other bits that make up Apache CouchDB.
Given just the core API you could store an entire static site as attachments on a single JSON document and serve each file from it's own URL. If that single document is a _design document, then you get the added value of the rewriter.
Here's an example faux JSON document that would do just that:
{
"_id": "_design/site",
"_attachments": {
"index.html": {
"content_type": "text/html",
"data": "..."
},
"images/logo.png": {
"content_type": "image/png",
"data": "..."
},
"rewrites": [
{
"from": "/",
"to": "index.html"
}
]
}
The actual value of the "data": "..." would be the base64 encoded version of the file. See the Creating Multiple Attachments example in the CouchDB Docs.
You can also use an admin UI for CouchDB such as Futon or Fauxton--available at http://localhost:5984/_utils--both of which offer file upload features. However, those systems will require that the JSON document exist first and will PUT the attachment into the database directly.
Once that's completed, you can then setup a virtual host entry in CouchDB (or Cloudant) which points to the _rewrite endpoint within that design document. Like so:
[vhosts]
example.com = /example-com/_design/site/_rewrite/
If you're not hosting on port 80, then you'll need to request the site at http://example.com:5984/.
Using a _show function (as in your example) is only necessary if you're wanting to transform the JSON into HTML (or different JSON, XML, CSV, etc). If you only want static hosting, then the option above works fabulously. ^_^
There are also great tools for creating these documents. couchapp.py and couchdb-push are the ones I use most often and both support the CouchApp filesystem mapping "spec".
Hope that helps!
Related
I'm designing a REST API using NodeJS and Express for managing different types of documents (txt, pdf, doc, etc). The document model is something like:
{
id,
category,
name,
path,
tags,
etc..
}
I currently have a route to GET a single document.
/documents/:id
This route serves up the actual document. I would love some guidance on the proper way to serve up the document details (i.e. the name, category, etc). Should I use a different URL? Send details in headers? Use response.format? Make the client specify via query?
Edit: I should clarify that the documents will be stored on the server filesystem and will not be directly accessible by any client.
If the document details are coming from a different source, the most straightforward way is to set up a different endpoint, /document-details/:id.
Otherwise, if a document can be stringified into a JSON, you could nest both in the same response:
{
document: {},
details: {
category,
name,
path,
tags
}
}
I would recommend against sending any detail about document in the HTTP header, those are usually used to send the details about the response itself.
First of all - all code on PHP and JS.
I took all user data (sub, base_uri, account_id ) with that documentation https://developers.docusign.com/esign-rest-api/code-examples/config-and-auth at my site using cURL
Now I need send pdf file for that I generate at my site with that access for user sign like I have understood I need that https://developers.docusign.com/esign-rest-api/code-examples/signing-from-your-app and Envelopes: create https://developers.docusign.com/esign-rest-api/reference/Envelopes/Envelopes/create#examples
I send POST request to https://demo.docusign.net/restapi/v2/accounts/{accountId}/envelopes with accountId=account_id from user data, also I send json with user data and doc data in base64 in, but there is nothing, so I don't understand:
How should I call "create" method with POST to https://demo.docusign.net/restapi/v2/accounts/{accountId}/envelopes ?
What Id should I use in {accountId}?
At what format should I send the document for the sign?
Where can I find that doc after create?
Can you show me code example or show documentation with normal examples of POST request for that method.
If you are using a demo environment, I believe your authentication url is https://demo.docusign.net/restapi/v2/login_information. For production accounts, since the subdomain can be different you can find the correct baseUrl using a GET request to https://www.docusign.net/restapi/v2/login_information?api_password=true using Postman. This gives you the right baseUrl as well as your authentication information.
Here is how you can create a template using a base64 which is a POST call to {{baseUrl}}/templates
{
"documents": [
{
"documentBase64": "<insert encoded base64 here",
"documentId": "1",
"name": "blank1.pdf"
}
],
"envelopeTemplateDefinition": {}
}
Also, if you need to generate more requests make sure you check out the Postman collection that contains different examples as Sebastian mentioned too:
DocuSign Postman Collection
I am new to Solr and PySolr and I am trying to create a web-app. I am planning to use PySolr but when I try to run an example script I get errors. Below are the details:
import pysolr
# Setup a Solr instance. The timeout is optional.
solr = pysolr.Solr('http://localhost:8983/solr/', timeout=10)
# How you'd index data.
solr.add([
{
"id": "doc_1",
"title": "A test document",
},
{
"id": "doc_2",
"title": "The Banana: Tasty or Dangerous?",
},
])
Then I get an error:
pysolr.SolrError: Solr responded with an error (HTTP 404): [Reason: None]
After looking up I found that the URL entered must not be correct, so I changed it to my collection's URL.
solr = pysolr.Solr('http://localhost:8983/solr/#/gettingstarted/', timeout=10)
Now I get the error below:
pysolr.SolrError: Solr responded with an error (HTTP 405): [Reason: None]
HTTP method POST is not supported by this URL
There are tons of questions on the above two errors, but all the resources I found are mostly dealing with some other specific scenarios. So, my question is that how do I give pySolr the correct URL and if the second URL is correct then how to deal with the above error.
The # part of an URL is never sent to the server - it's a local anchor that only the client itself should access. The URL you're using is the admin interface URL that the javascript in the admin interface uses to set up the current page to show.
The core is available directly under /solr, so the correct URL should be http://localhost:8983/solr/gettingstarted/.
You can also see this in the query interface inside the admin interface when making queries (the URL is shown at the top - you're interested in the part without the select handler).
i'm using the Box View API to convert a PDF file to HTML, i'm using the /documents/{id}/content.{extension} section.
The response for this GET call is a .zip file, however i don't know how to retrive it and make downloadable.
Also note that i'm using node.js.
Thanks for your help
You can set your own webhook URL that will be called by Box when your document status changes (one POST on your webhook for "document.viewable", and one for "document.done" plus one "document.error" if an transformation error occured).
Just listen to the "document.done" status and download the assets then. Format that is posted to the webhook you have set looks like :
[{
"type": "document.done",
"data": {
"id": "4cca28f1159c4f368193d5014fabc16e"
},
"triggered_at": "2014-01-30T20:33:04.798Z"
}]
Beware of the docs and check the format programatically. Their API docs are often no quite correct and they post multiple webhooks at the time i'm writing (which is a bug i've reported).
For more info and Box View API docs
How do you update a SharePoint 2013 wiki page using the REST API?
Three permutations:
Reading an existing page (content only)
Updating an existing page
Creating a new page
For reading an existing page, of course I can just to a "GET" of the correct URL, but this also brings down all the various decorations around the actual data on the wiki page-- rather than fish that out myself, it would be better if there was a way to just get the content if that is possible.
Are there special endpoints is the REST API that allow for any of these three operations on wiki pages?
As stated in GMasucci's post, there does not appear to be a clean or obvious way of instantiating pages through the REST API.
You can call the AddWikiPage method from the SOAP service at http://[site]/_vti_bin/Lists.asmx. This is an out of the box service that will be accessible unless it has been specifically locked down for whatever reason.
To read the content of a wiki page through the REST API, you can use the following endpoint:
https://[siteurl]/_vti_bin/client.svc/Web/GetFileByServerRelativeUrl('/page/to/wikipage.aspx')/ListItemAllFields
The content is contained within the WikiContent field. You may want to add a select to that URL and return it as JSON to reduce the amount of data getting passed over if that is a concern.
As for updating the content of an existing wiki page, it is not something I have tried but I would imagine it's just like populating another field through the REST API. This is how I would expect to do it:
Do a HTTP POST to the same endpoint as above
Use the following HTTP headers:
Cookie = "yourauthcookie"
Content-Type = "application/json;odata=verbose"
X-RequestDigest = "yourformdigest"
X-HTTP-Method, "MERGE"
If-Match = "etag value from entry node, returned from a GET to the above endpoint"
Post the following JSON body
{
"__metadata": { "type": "SP.Data.SitePagesItem" },
"WikiField" : "HTML entity coded wiki content goes here"
}
The interim answer I have found is to not utilise REST, as it appears to not be
fully documented
fully featured
supported across Sharepoint 2013 and On-line in the same way
So my current recommendation would be to utilise the SOAP services to achieve the same, as these are more documented and easily accessible.