The requirement is to send a request to workday create position endpoint and create a position through the API. according to workday community, Request body has certain fields to be filled. https://community.workday.com/sites/default/files/file-hosting/productionapi/Recruiting/v31.2/Create_Position.html
could anyone help me with filing the request body?
Related
Suppose any REST api is exposed over the net which has post method and has some request body. Now how would I know what are the expected request body of that REST api?
Create a sample/test API for this purpose. Server will return the sample of the object that you need to send in next API request body. So, call the this GET API to know what and all key need to be send.
I have created an envelope, added recipients and documents to the envelope through REST API call in apex code. Now I want to view my envelope in docusign user interface before ot it sent to the signers. Can I connect to the docusign from REST API call in apex and view the envelope?
There are different type of views you can use, based on the Envelope status, details are available at https://docs.docusign.com/esign/restapi/Envelopes/EnvelopeViews/ You might be interested in seeing https://docs.docusign.com/esign/restapi/Envelopes/EnvelopeViews/createCorrect/ or https://docs.docusign.com/esign/restapi/Envelopes/EnvelopeViews/createEdit/ or if sender wants to see it then https://docs.docusign.com/esign/restapi/Envelopes/EnvelopeViews/createSender/
You can use the EnvelopeViews: createSender API (also called Embedded Sending) to open the "tag and send" view of the envelope and let your users send it through the DocuSign Console. This also allows them to make changes to envelope before sending, given that they have the correct permissions.
This is what the API request typically looks like:
POST /v2/accounts/{accountId}/envelopes/{envelopeId}/views/sender
{
"returnUrl": "https://your.app.com/callback"
}
Once the user is done sending the envelope they will be redirected to the URL that's provided in the returnUrl parameter.
I'm designing a REST api that allow client side to POST (create) a resource.
Let's call my resource is Subscription and my REST api accepts a Dto called Subscription
The POST request needs to be sent together with a captcha token that will be verified on server side.
My question is where would be the best place to put the captcha token, there're some options that I'm thinking about:
Directly inside Subscription
As a parameter in URL, e.g: /subscriptions?captcha_token=abcd1234
As a HTTP header
Create a new Dto that wraps Subscription and carry field captchaToken
Any other suggestion are welcome.
Thank you.
For anything authentication or authorization related I typically rely on headers or querystring parameters.
Generally I don't like to commingle payload with auth-related material, nor do I like to encapsulate it.
Having it in an HTTP header or as a querystring parameter gives you a good amount of isolation there. Also since it's independent of the request body you can implement broader auth controls for every API call without being dependent on the presence of a request body (important for GET requests which shouldn't carry a request body anyway).
Using a HTTP Header is only an option if your clients can modify / send HTTP Header information. This approach does not work for Standard Browsers.
You are not filtering a resource, so a query parameter from the REST Point of view does not make sense, and you don't want to send the captcha answer as query parameter.
Usually the one submits the captcha information (id, answer) together with the form data (payload). You also usually display captchas together with the form.
So at the end the only useful option is to send the captcha information as part of the payload / form data.
If you should put the data into your Subscription DTO or not depends on your design / preferences.
I'd suggest to use something like a Subscription(Data) and SubscriptionRequest where the SubscriptionRequest contains the SubscriptionDataand the Captha Information (capcha id and answer)
I would like what happen when an web service receive part of data by SOAP header. What's the diference between receive data by SOAP header and SOAP body (Before the web service receive all of data by SOAP body)
I don't understand at all what are benefits of this new version.
PD: My web service is based on Java with JAX-WS
Thanks a lot.
Same as any request SOAP has header and body. generally SOAP has all data in body.
Body is highly documented so you can not send additional data in SOAP body.
If you are doing It may break the other end code(Implementation in different for different technologies).
SO if you want to send additional data in SOAP without effecting the WSDL you can use SOAP header.
Headers are like to send additional information.
these header and values can be accessed from message context.
to access these value code may vary from technology to technology
I'm having issue using DocuSign API. when I send a PDF via SOAP API. (I am using the method CreateEnvelopeFromTemplates, the templates are on your server) When the user received the envelope (PDF) the fields are not there. But when I send via the WEB they do have the fields.
I was not adding the Role to the API, now I'm but still not showing the fields.
Should I use the method CreateEnvelopeFromTemplatesAndForms instead the other one?
I believe you're using the right method (CreateEnvelopeFromTemplates). The most likely reason that the fields (tabs) are not being displayed when you create the Envelope via the API is that the recipient Role Name(s) being specified by the API request does not exactly match the Role Name(s) specified by the Template itself (with which the tabs are associated). Make sure spelling, spacing, and case of Role Name(s) specified by your API request matches exactly with what's specified by the Template.