SOAP or REST? Which one to use please? [closed] - docusignapi

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I'm starting to learn DocuSign to see how I can integrate it into our current solution and I need your help to pick which SOA technology to use? I know how to use both SOAP and REST and I'll use Java.
My manager asked me to select one technology to use and I need reasons to tell him why I pick one technology over the other. Here are my questions to pick one over the other.
1) Does DocuSign offer the same services for both SOAP and REST? In other words, it does not matter which technology I use, I still be able to access all services DocuSign offers???
2) Simplicity - I heard REST is simpler than SOAP???
3) Any other reasons that you have, please let me know.
Which technology do you recommend for me to use please, SOAP or REST?
Thanks

From the DocuSign perspective, it comes down to personal preference (REST vs SOAP) for the most part -- there's no single compelling/mandatory reason that you would necessarily have to choose one over the other. That being said, here are some thoughts, in no particular order:
The DocuSign SOAP API has been around longer; the DocuSign REST API is much newer. Recently, it seems, new operations are oftentimes being added only to the REST API (and not to the SOAP API. (See the first paragraph here: http://www.docusign.com/developer-center/explore/soap-api)
The operations (i.e., features/functionality) available in the DocuSign SOAP API versus the DocuSign REST API are largely the same -- but the APIs are by no means 1:1 in terms of operations/features/functionality -- there are differences between the two.
There's no reason why you can't mix SOAP and REST within your implementation. i.e., Let's say you're most comfortable working with REST, so you choose that. If you discover at some point that you need an operation that's only available in SOAP, then just make that one call using the SOAP API -- leaving all the remaining calls using REST.
DocuSign SOAP API Requests tend to be larger in size than DocuSign REST API Requests -- which is fairly typical of any SOAP versus REST comparison.
The DocuSign SOAP API might be considered more powerful (efficient?) in some ways, in that there are things you can do with a single DocuSign SOAP API call that can only be achieved by making multiple DocuSign REST API calls.
I'd recommend that you checkout the DocuSign Developer Center for more information about the DocuSign APIs: http://www.docusign.com/developer-center

Related

What programming languages are required for the ServiceM8 API?

I am currently on the look out for a backend web developer but before I search for one I need to know the programming languages to find the right person.
ServiceM8's customer service team told me Python for web and Swift for app. Can I confirm this? You can see their API doc here: https://developer.servicem8.com/docs/getting-started
I am not sure what the difference is here (I know they are both programming languages, but not sure when they'd be used).
Thanks!
Dmitri.

DocuSign: What API endpoint or method is used to retrieve a list of power forms stored in the account?

I asked similar question, but docusign support said post our question to stackoverflow again.
My prevuis question is https://stackoverflow.com/questions/28152052/docusign-how-to-get-power-forms-from-api
There is not currently a way for REST to return this information, I believe it is in the plans to be released, I'm just not sure when.
SOAP does not have this functionality, and I don't think it's planned to add as a feature either.
When it is supported in REST the path should be:
GET https://{server}/restapi/v2/accounts/{accountId}/powerforms

Looking to integrate echosign or docusign with our zoho crm [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 1 year ago.
Improve this question
I am looking to integrate echosign or docusign with our zoho crm. So that the information that is put into the contract is transfered into our crm. We currently use Zoho CRM is there anyone that knows if this is possible? If so where could i find anyone that could do this since i do not know anything about programming?
Thanks
DocuSign can be integrated with any language / platform that can make RESTful HTTP requests. Furthermore, DocuSign has major advantages over EchoSign, such as the more features (ones that actually matter), more flexibility, a MUCH bigger network (48 Million unique users), and is available in 188 countries and 43 languages. Perhaps even more important, on average the DocuSign service has been available 99.99% for the last 5 years, EchoSign has had major publicly known outages.
So yes, you can definitely integrate with Zoho CRM and some people have probably already written custom integrations that do this. The normal path to take is to simply write your own integration using the DocuSign REST API
Also, doing a web search seems to yield several companies that can specifically integrate DocuSign + Zoho CRM for you if you are not a programmer. If you / your company is not going to be coding it yourself then check out these:
CloudWork
Zapier
And you could always use E-Lance and sites like that as well.
It's absolutely possible with DocuSign. To achieve this integration, you'd do the following:
Collect data from signers during their DocuSign signing sessions
using "DocuSign tabs" (i.e., DocuSign-specific form elements that the
sender places on the document representing text boxes, checkboxes,
dropdown-lists, etc.)
Build a "listener" application and configure DocuSign Connect to send XML messages to your listener application when an Envelope is completed.
Design/build your listener application to receive and process the DocuSign Connect messages -- in your case, "processing the DocuSign Connect messages" would mean reading the "DocuSign tabs" data in each XML message and then using the Zoho CRM API to update records in Zoho with data from the DocuSign tabs. (Note: You can also configure DocuSign Connect to include the completed documents themselves in each message -- doing so would allow your listener application to also store the completed document(s) in Zoho.)
You are right to check with the developer community before investing into any platform. The short answer is DocuSign API is your best choice. Aligning yourself with a dominant API provider will ensure that:
you can find developers easier
the bugs have been discovered by someone before you and fixed
that the platform has all of the comprehensive features and you will never be stuck.
DocuSign discussions dominate StackOverflow: https://stackoverflow.com/search?q=docusign (over 300 and most are answered) and https://stackoverflow.com/search?q=echosign (45 and half are not answered).
Elance has double the freelancers that work with DocuSign vs EchoSign.
With DocuSign DevCenter (which was named as #1 by ProgrammableWeb eSignature API report http://blog.programmableweb.com/wp-content/esignature-api-report1.pdf) you have PHP samples for 9 most common scenarios meaning that your developer can get up and going with the integration a lot faster. There are also 5 other languages there for whatever comes up.
DocuSign also have an interactive API tool iodocs.docusign.com which will allow you to debug your integration simpler.
In closing DocuSign is integrated with hundreds of applications and actually quite a few of those had to redo their integration because they picked another eSignature provider first and hit reliability issues or feature gaps. Do not make the same mistake.
Here is an incomplete list of publicly available software that integrates with DocuSign: http://www.docusign.com/partners/solution-showcase
Let us know if you have any questions.
I have integrated Zoho CRM / Zoho Creator with DocuSign before. Here's what the integration looks like:
Creator form looks up record from CRM
Creator form populates form fields with CRM record data
Creator form validate script uses DocuSign API to fill out DocuSign template with form data and send the envelope
DocuSign sends response back
Creator parses response to see if the action was successful
Contact me if you need help. This isn't super easy to set up but I've done it before.
Integrating EchoSign with ZohoCRM is absolutely possible. EchoSign has a complete set of APIs that can be used for integration. We use our own APIs to build our integrations with other systems such as Salesforce.com, Microsoft Dynamics, etc. These APIs have also be used by multiple customers to build integrations into their internal systems. We know for a fact that the APIs are sufficient to build integrations into external systems.
You can get information about the EchoSign API at https://www.echosign.adobe.com/en/products/echosign-api-dev-center.html. Additionally if you have any questions please send email to api at echosign.com and we will be able to help you with your integration.
Thanks
Mangesh

Is there a social networking protocol [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
Social networking is great, but there is something fundamentally wrong with the way social networking is implemented today in most popular services. I'll put it in this example: Imagine that there is no SMTP, and consequently, it is globally assumed and accepted that you can only send email to addresses on the same domain. The result would be the emergence of a single email service, let's call it emailbook.com, which we all have to subscribe to, if we really want to communicate with the world.
This is what's happening with social networking today. You HAVE to use the same service your fiends/colleagues are using to talk to them.
I would like to be able to put up my own social site, invite my friends who trust me, share amongst us, but still be able to share with the world at large.
What are the chances of this scenario happening in the future? What does it take?
There sure is, and not just one! The future you wanted is now here.
By the time of the question, back in the end of 2010, OStatus had already existed for half a year, and the year before that there was OpenMicroBlogging (OMB), and at about the same time as OMB, the XMPP XEP 0277.
Since then several other protocols have popped up, such as diaspora* just half a year later, and later some smaller players like Friendica's DFRN and HubZilla's Zot.
OStatus never left draft status, but the big buzz[0] these days is about ActivityPub, which is a W3C recommendation since January 2018 and came out of the Social WG mentioned by #keithjgrant in his answer. There is a multitude of implementations[1], finding their niches with different use cases like microblogging, blogging, link sharing, picture sharing, video sharing and audio sharing.
There is also the collection of blog-oriented protocols described on https://indieweb.org/.
[0] pun intended
[1] Diaspora and GNU Social, although shown at fediverse.party, do not implement ActivityPub. The other applications shown do. There are several other applications not shown there, such as FunkWhale, Plume, WriteFreely, Prismo ... There is no terse and complete overview of all of them, but several are listed at https://switching.social/ and https://wedistribute.org/ publishes news and interviews related to all of them.
There are a few. One Social Web uses XMPP which is open and decentralized like SMTP.
Check it out.
http://onesocialweb.org/
I absolutely agree. The good news is, yes, things are happening. Even better, they are happening in the W3C, which means open standards.
The W3C now has a Social Web working group. They are actively working on a handful of standards. The biggest of these seems to be the Social Web Protocol.
Today, they also posted the W3C Recommended spec for Webmention, which is sort of an improved version of the old pingbacks that used to be used on blogs, this time built on HTTP. It allows a post to notify another page on the web when it references it. There are already a number of libraries and services that implement this today.
I think you should take a look at http://code.google.com/apis/opensocial/. It is a spec developed by google and other social networking players. It supports interoperability and much more.
OpenSocial is currently being developed by a broad set of members of the web community. The ultimate goal is for any social website to be able to implement the API and host 3rd party social applications. There are many websites that support OpenSocial, including hi5, LinkedIn, MySpace, Netlog, Ning, orkut, and Yahoo!

Document Management [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
We looking for a simple, open source, web based document management system for Linux. With document management I mean the ability to store a set of files (minimally doc, xls and pdf) as a document. Associate meta data with the document like owner and version. Update and delete documents. Ability to index and search content. Authentication and the ability to authorize at least read, and possible write. If possible I would like to avoid implementations in Java or PHP, and as we use MySQL already that would work especially well for meta-data storage.
We have used Google Applications in the past but the lack of support for PDF makes it a poor fit. Other downsides include their service losing some of our spreadsheets, no concept of company owning information opposed to individual accounts, and some of our information is sensitive and we prefer keeping it in-house (passwords, contracts etc).
MediaWiki was not a good fit either as our documents is really a set opposed to be structured content (i.e. not looking for a content management system), and at least the version we had installed did not deal well with attachments.
Based on review of past questions I plan on looking into KnowledgeTree. Any other projects that we should consider?
I've been using KnowledgeTree now for a few months developing an ASP.Net application and I only have good things to say about it. Our product uses it for PDF storage/retrieval and it really couldn't be easier to deal with. The basic install gives you a simple environment with almost endless amounts of configuration for meta-data, document groups, and various security options. Also, the KnowledgeTree staff have been very helpful and have provided us with sample code when we have run into 'how are we going to do that?' moments.
I'll second the recommendation for KnowledgeTree. Have been using it for a couple years and have roughly 1K documents indexed. Sometime last year, I wrote a short script which monitors KT's transaction table (in MySQL) and notifies users of new or updated documents via Twitter, Identica, and/or Jabber. The Twitter/Identica feeds can then be monitored with a RSS reader.
Look for something that will index all your document formats and keep them searchable.
I solved this in my office using Coldfusion. It has verity search engine built in. This indexes files on your network (doc/xls/pdf, etc) to make the text in them searchable (like google).
An instant search engine for all my files, for upto 150,000 or so is built in for free with Coldfusion so it suits my purpose.. Something like this would allow you to save your files on a network how/wherever and you'd be able to extract the rest of the information about owners, modification dates through libraries available in java / .net.
I am sure you could replicate this with another language, but probably a bit more effort. I am presently wishing I could use the Google Docs API as a wysiwyg editor in my own wiki in-house.. that would solve most of my problems then because everything would be intranet based.
Try https://www.mayan-edms.com, written on Django, db agnostic
You can consider GroupDocs as they have got storage, conversion and few more features.

Resources