I know this at least IMO is a stupid request. Because WSDL is old hat and sucks compared to just doing a RESTful API. But I have a corporate "mandate" where we want to do a REST API but then corporate wants a WSDL still. I know..it makes no sense and apparently we can't push back and say NO and tell them to just use our future REST API.
So can you generate a WSDL if I were to start creating a REST API with ServiceStack? Meaning I add uri attributes and such? So that I can "make them happy"?
I prefer not to use WCF, it's a nightmare with a ton of attributes and configuration to try and hack a RPC style web service to try and be RESTful. Obviously that doesn't work out too well.
SOAP along with REST is supported and you can have REST API along with soap wsdl. There are some recommendations posted in servicestack wiki that you can review and get started! You just need to implement the restful service and soap, json, xml etc are automatically supported.
Related
So i want to develop a simple web application, which will basically be a basic form which on submission will allow to make an external api request. So are there any application designers that can allow to do that with minimalistic code. Appian for example has an interface/application designer that lets you drag and drop a UI interface and build a workflow, make api calls externally or to a database. So like that are there any other apps that allow to do something similar (make api calls/build ui easily/store in databse)? Any other suggestions are also welcome!
It heavily depends on the API as well as the kind of task you´re trying to achieve.
Here´s just a few examples and considerations. (All the below supposes that we´re talking about Web-Based APIs).
If the API requires authentication of some sort and the user authenticates himself: A simple HTTP file with JavaScript to send the request will do the job
If the API requires authentication but you authenticate for all the users: You will need a backend application that does the API request since you need something secure where you can put your Auth-Details for the API. Classic PHP or NodeJS in combination with a served HTTP file for the form itself would work without any JavaScript (depends on the API definitions)
If the API does not require authentication maybe a simple HTML form would work
If you want to write to a database you can have a look at something like https://directus.io/. They allow building a database with a UI and they automatically generate a Web-API which you can then feed by your forms. If the end-user is known to you Directus actually allows users to log in and fill the database with forms that you can visually design but this is rather for employees entering data into an internal database than customers submitting their contact data to you
From my personal experience, all the UI-Tools that promise to integrate with REST APIs make it really hard to do so since every API is different and there is no real standard for them.
I have been looking for a way to make API calls to the Docusign REST API using strictly client-side javascript (no Node). I haven't been able to find a single example of how to do this which leads me to believe it's not possible for some reason.
Furthermore I haven't seen an SDK for client side javascript calls. Only the following are available: C#, Java, Objective C, Node, PHP
https://www.docusign.com/developer-center/api-overview#sdk-docusign
So my question is this, is it possible to make purely client side calls to the Docusign API?
Not fully from a client side, due to CORS restrictions for security purposes.
I am very new to Salesforce and it's API.
I am having a sandbox org and with it I have url, username, password, security token and last but not the least partner.wsdl
My aim was to connect and retrieve/create data.
Technologies at hand was nodejs
So here is how I started.
I searched over the internet and came to know that I need to create a client, SOAP client in order to login, create the connection and use that connection to create and access the Leads data.So I followed this sample where the wsdl was being consumed.
So I was able to connect
I was very happy on this success and then suddenly I wasn't able to identify/find a way where I can get the sObject.I looked hard for this but no luck. So posted a question on SO
Meanwhile I also looked for other node module and found jsforce
I used jsforce starting guide and created a client that was connecting to salesforce however without using the wsdl file.
Again I was happy, even more happy because I was having the sObject with me.
Now, what is the fundamental difference if I login using the local wsdl file and without wsdl file in the language of salesforce. Which one is the correct way of logging in?
Sorry if this question is not according to SO rules or if there is a typo.
I'm the author of jsforce you mentioned.
In that lib we use REST API mostly and SOAP APIs are only used in some specific calls like login or metadata. Even in such calls we don't use WSDLs because there's no good lib to generate client modules from WSDL in JavaScript/Node.js area. Instead we wrote modules for each APIs which generate SOAP XML strings and parse the response XML.
It is enough because these API message schema are static and fiesible in the specific version, unlike SOAP API Enterprise WSDL differs in organizations. So we can hard code the client module directly w/o generate it from WSDL.
I'm struggling to see how this is RESTful. I'm referring to the downloaded GitHub ServiceStack.Examples\src\ServiceStack.Examples\ServiceStack.Examples.sln. I do not see anything restful about this, there is no RESTful routes here at all and the method names are all verbs but they're all like GEtThis, etc. I don't see any Http verb attributes, nothing here.
Can someone explain what this is here becuase I feel like it doesn't even belong in the ServiceStack examples...??
Nobody said that example was supposed to be RESTful.
ServiceStack is a general services framework that lets you implement SOAP, MQ or REST+Web/HTML services with the same service.
The example your looking at is one of the first examples ever created for ServiceStack which makes use the Old API. You can compare and contrast it with the New API here. Since the example implements IService<T> it's not a REST service, since every HTTP Verb will invoke the same implementation above. To provide different implementations for each verb with the Old API you would need to inherit RestServiceBase<T> instead, or preferably use the New API.
If you want to consume this service via SOAP or MQ hosts than you need to ensure its accessible via POST by either maintaining single operation per Request DTO like this or by using a method named either Post() or Any() in the New API.
Parse is a Backend-as-Service platform that offers RESTful API for data storage and query. It seems very appealing for front-end or mobile developer and allows them to focus on business logic without worry about those troublesome back-end technologies.
The RESTful endpoint looks something like this:
https://api.parse.com/1/classes/GameScore
If I want to use this on my site, say awesomehtmlsite.com, wouldn't the request be blocked by cross domain restrictions? Same would hold true for the Javascript API.
Can someone explain to me how I can utilize the RESTful API or the Javascript API?
Responses to calls to the Parse javascript API include the following header:
Access-Control-Allow-Origin:*
This allows it to be used cross-domain. You should just be able to follow the JavaScript guide/API that Parse provides, without worrying about cross-domain issues.