I am staring at the DocuSign REST API Guide and I see no request to update, say, User LastName. It looks like DocuSign may regard this top-level information as immutable for security/identity purposes. These are the PUT operations I am seeing related to users:
/accounts/{accountId}/users/{userId}/custom_settings
/accounts/{accountId}/users/{userId}/profile/image
/accounts/{accountId}/users/{userId}/settings
/accounts/{accountId}/users/{userId}/signatures/{signatureIdOrName}
/accounts/{accountId}/users/{userId}/signatures/{signatureIdOrName}/initials_image
/accounts/{accountId}/users/{userId}/signatures/{signatureIdOrName}/signature_image
/accounts/{accountId}/users/{userId}/social
Yes, it looks like /accounts/{accountId}/users/{userId}/settings is what I am looking for but this request covers only userSettings, signerEmailNotifications and senderEmailNotifications.
Am I missing something?
Some of the functionality in DocuSign is not exposed to public API for security reasons. We don't want people to change people's identity for example. So not every single setting is going to have a full CRUD operation set.
Maybe it would be helpful to hear what you are looking to accomplish? Here is the list of common integration scenarios: https://www.docusign.com/developer-center/recipes - it might help.
Related
My HTTP API requires the frontend to pass an accountId on API calls due to the fact we support admin users who are not tied to a single account and could be querying any account.
Initially I implemented this as a header the issue here is that caching would not work.
The current implementation looks like api.com/endpoint?accountId=123 whilst this works well - I would like to understand if this is the correct approach when implementing a RESTful HTTP API.
UPDATE:
Based on a comment - this is for GET
IMO, you did things "the right way" (TM) by putting this information in a HTTP header -- that seems to be the correct place for this to live. However your caching system currently doesn't care about HTTP headers, so that leaves you with a practical problem (which doesn't really care about "the right way"). So...
Based on that, it sounds like you have two options:
Fix your caching to include specific headers as part of the cache key, or
Add relevant information to the URL for caching purposes
I'd suggest (1) where you update the cache key to be a hash of the URL + other relevant information that would result in a different result (in this case, the HTTP header including the account ID or session information). This allows you to keep putting information in the right place while also not causing issues for cached pages.
Of course this might not be possible, so the only practical solution I can offer you is (2) where you pull stuff into the URL in order to support caching. I think this is an anti-pattern, but it will get the job done.
When REST API don't follow HATEOAS style, it is often referred your REST is not truly REST.
How come we can think of every possible request from clients can map to CRUD operations?
For example if the client(mobile) would like to send a reset password link to user for a given email id, how this shall be thought of as CRUD?
Very few REST advocates will argue that that REST should be applied to everything. I'm a big proponent of REST, but there are more than a few situations where not using HATEOAS is the most pragmatic move. Your example is one of them.
However, if you want to make this work in a RESTful manner, it's totally still possible.
For example, a lost password reset link might require a one-time authentication token. This token might be represented by a resource in a collection such as:
/users/xyz/auth-tokens
And perhaps you can initiate a lost-password email operation by creating a new 'auth-token' resource in that collection using POST.
Should you? I don't know! Can you? for sure!
Creating a PasswordReset resource is easy enough.
POST /password-resets
RPC minded people struggle to switch over to REST because they're used to doing things as RPC. :)
https://www.smashingmagazine.com/2016/09/understanding-rest-and-rpc-for-http-apis/
My task is to implement a resource server(RS) for IdentityServer4(IS4). The RS should fetch data from a database and send the necessary information as a json object back to the caller (client). This is needed because we have to return complex objects.
I already setup IS4 succesfully and its already running in Docker for testing purpose. I also setup the needed database.
My understanding of the flow would be, the user requests data from the RS sending the access-token, the RS then validates the token, checking if the caller is allowed to access the api using the IS4, if everything is okay the RS returns the data to the caller.
My problem is, as I'm new to this subject, how would I implement a RS? Do I create an API which is added as a scope to the user? Or is there a RS already implemented in IS4?
So yes you'll need to write your own API to serve your own resources, IdentityServer will only manage your identities for you (as well as handling external logins if that's what you need). I'd recommend going to the IdentityServer docs and working through the quick starts in order as shown below:
This will give you a good start but you'll then need to go away and research APIs more generally, there's a tonne of good info online about building (RESTful) APIs. You may find it useful to sign up to something like PluralSight and work through a couple of their courses, they're often very good.
One other thing to bear in mind is that IdentityServer is for identity, in other words Authentication and not specifically for Authorisation so you may need to add something for this. You can of course use a users identity for authorisation purposes but in most cases you'll probably need to augment the info you store about their identity to authorise them for access. See this link for more info around this topic.
Do I need to use a form (formbuilder) to submit POST Data to symfony? For example login by xml or something like that?
I'm confused as there are people telling me I have to, and on the other hand there an some who tell me that I don't need to because I use it as a REST api???
It would be great if we can go through the possibilities I have with REST and CRUD.
I'm a bit confused because in case of a login, I don't want to nind a request to a form or an entity or is this the only way handling eg. login data?
Thanks in advance for your help.
Actually I think it's your own choice. There is no requirements to do things in single way. Do you think you need form - use form, no - no.
I think if action from your REST API doesn't relate to any entity it's absolutely not necessary to use forms. But if the action is aimed to handle CRUD request (POST or PUT) it's more convenient way to use forms. But anyway it's only your choice.
In some cases (in standard and pretty simple cases) it's much easier to use form and I think it's the best and fastest way to make something work. But if you need to customize form it might be too difficult and might take some time to solve all of the issues.
One approach to "login" is to think in terms of access tokens.
POST /tokens with a payload (xml or perhaps json) of user name and password. The server authenticates the user, then generates and returns an unique token linked to the user.
On subsequent REST requests, include the token in the header of the request. From the token, the server can determine the user and access protected resources accordingly.
http://symfony.com/doc/current/cookbook/security/api_key_authentication.html
This of course is only one approach that has worked for me.
===========================
By the way, #Alex of course answered your actual question on forms.
I'm designing a rest api about Quiz System, user need to login to do the quiz , there are functions like GetQuiz,GetQuestion.
And other set of api for management of those user and quizs, there are functions like
AddQuestionToQuiz,DeleteQuiz,CreateUser
Now i am confused about how to design it.
Thanks in advance!
You need to think in resources and not in method calls. A quiz might be a resource, a user might be a resource, a question might be a resource. All resources support GET, POST,PUT, DELETE.
Sometimes to help me think it through, I think what a website would look like where the resources are HTML and it has links (hypermedia)
HTH