If an item is removed using the remove endpoint, does that make the access_token not valid anymore? is that effectively the same as destroying the token?
Basically yes.
As stated in Plaid docs :
The /item/remove endpoint allows you to remove an Item. Once removed, the access_token associated with the Item is no longer valid and cannot be used to access any data that was associated with the Item.
Related
In this article: https://mailchimp.com/help/about-your-contacts/ it lists the status options as:
Subscribed
Unsubscribed
Not-Subscribed
Cleaned
By passing in "subscribed" or "unsubscribed" as the status, this will update, however I cannot find a valid value to pass in for people who are Not-Subscribed.
"Pending" puts them into a pending state which triggers an email to be sent to the user to approve. The API doesn't allow you to leave it blank.
Is there a way to do this? In an ideal world, I want to allow the system calling the API to set subscribe/unsubscribe after further action from the user, while still initially adding them into the contacts list.
According to the Mailchimp API documentation, these are the only possible values for a subscriber's current status:
"subscribed"
"unsubscribed"
"cleaned"
"pending"
I suggest trying null if possible, or leaving the value empty as status= to see if that works. Otherwise, documentation is law.
Edit:
Untested, but you could also try passing an empty value using %02%03 as the contents of the value, given that %02 denotes the start of an ASCII character and %03 denotes the end of an ASCII Character. Success would depend on whether the Mailchimp server would allow it.
Specifically, can SCIM be used to add Users to pre-existing (non SCIM-created) groups? We need to provision users via SCIM, but then add them to Groups created manually in the site (a .Net application).
As I understand it, it can't be done like this. Group Update requests (i.e. PATCH requests) seem to require the "id" attribute as the unique identifier for the group, and this "id" seems to be only generated in SCIM Create Requests. So if a Resource (Group / User) wasn't originally created via SCIM, SCIM can't update/replace/delete it. Is that correct?
e.g. PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
I thought about a workaround convention, such as using "user:1234" and "group:1234" as the "id" attribute format (i.e. [resource type]:[internal type-specific ID]), and then any User or Group can be specified by "id", even if it wasn't created via SCIM. But that seems pretty hacky.
Is there a better way of doing this? Many thanks for any help, very new to SCIM!
Yes, SCIM can be used to manage "brownfield" scenarios where existing non-SCIM created objects exist.
Typically the logic flow that happens for a user object is:
GET on /users with a filter (as defined in RFC7644 3.4.2.2) using an attribute that is uniqueness constrained (such as userName, email).
If no user found matching that criteria, create a new user with POST to /users
If a user was found, it should bereturned with an id value even if it was not created via SCIM
The general logic of "Search using a friendly identifier -> create if not found/cache the id value and associated it with existing user in the other directory" is pretty simple and can be successfully used with other object types (ie: groups) as well.
I have been unable to return any UserDefined/custom fields for a contact. I'm not even wanting to create or update an existing entry as per Programatically adding "New Custom Field" To Google Contacts using Google contact API
I have followed the guide here https://developers.google.com/google-apps/contacts/v3/reference, but still to no avail.
I've called both
https://www.google.com/m8/feeds/contacts/default/full?alt=json
and
https://www.google.com/m8/feeds/contacts/default/full/DEADBEEF?alt=json
in an attempt to get ALL of the values returned. I thought I might have to call each contact id specifically to get the full details, but that doesn't work either.
DEADBEEF is clearly replaced with a valid contact id in my scenario.
/contacts/default determines that request should return contacts for the current auth'd user, which is myself in this case.
Has anyone managed to return custom values, is this even possible?
Thanks
I found the answer, add the ?v=3.0 to the url string eg
https://www.google.com/m8/feeds/contacts/default/full/DEADBEEF?alt=json&v=3.0
However, you should use the preferred method of adding a GData-Version header.
Should we create a PUT or DELETE request for a Logical Delete in Web Api ? I-e setting a flag IsDeleted = 0 or 1
The REST school of thought for Web API maps HTTP verbs to operations on resources, and the typical mapping looks like this:
GET = READ
POST = CREATE
PUT = UPDATE (though sometimes PATCH is used in place of PUT, and PATCH may arguably be more correct)
DELETE = DELETE
The question I'd ask, then, is whether the fact that the delete operation is logical, rather than physical, transparent to the consumer of the API? If the expectation of the API consumer is that they're deleting a record, then I'd use the DELETE verb for the request.
Yes, you could use PUT/PATCH to update the IsDeleted field, and it would not be wrong per se, but I would look at this from the perspective of what the API consumer expects in order to decide which is right in this situation.
I have a SPA (single page application) so it uses AJAX extensively for getting and saving data to and from the server. In one case I allow the admin to view/add/edit/delete users. Some current urls for this area looked something like:
(GET) /users?userId=1 // get user with id of 1
(POST) /users?userId=1&firstName=Jim // update the first name of the user with id 1
(POST) /users?firstName=Bob // create a new use with the first name Bob
(POST) /users?userId=1&delete=true // delete user with id of 1
Having spent some time working on a RESTful API in a related project, I'm wondering if it's preferred to use HTTP types (GET, POST, PUT, DELETE) in a web app as well. Also, is it better to use a path parameter for user id instead of a query parameter? So are these urls (rewrite of the ones above) a better option in the long run:
(GET) /users/1 // get user with id of 1
(PUT) /users/1?firstName=Jim // update the first name of the user with id 1
(POST) /users?firstName=Bob // create a new use with the first name Bob
(DELETE) /users/1 // delete user with id of 1
In theory yes you should. You should be as RESTful as possible which means using HTTP semantics to their fullest. However the reality is a bit more murky, several older browsers, I don't need to name names, don't support anything but GET and POST. So the current recommendation until those browsers go out of support, or until you drop support for those browsers, is to have backup methods that do the same thing but on POST, usually with an extra parameter or segment in the url.