i am new at rest api azure and i dont know how to get correct body template of policy.
For example i used :
GET https://dev.azure.com/organization/project/_apis/policy/types?api-version=7.0
and the response are types of policies which i can use but how do i know the construction of the request body? Like this one:
{
"isEnabled": true,
"isBlocking": false,
"type": {
"id": "fa4e907d-c16b-4a4c-9dfa-4906e5d171dd"
},
"settings": {
"minimumApproverCount": 4,
"creatorVoteCounts": false,
"scope": [
{
"repositoryId": "a957e751-90e5-4857-949d-518cf5763394",
"refName": "refs/heads/master",
"matchKind": "exact"
}
]
}
}
Where should I find those request body templates? :(
Resources: https://learn.microsoft.com/en-us/rest/api/azure/devops/policy/configurations/create?view=azure-devops-rest-5.1&tabs=HTTP
Usually, when you could list or get the repo policy correctly, you could use the parameter configuration part of the returning result as the request body in creating the policy with post method.
rest api to list the branch policy.
GET https://dev.azure.com/{organization}/{project}/_apis/policy/configurations?api-version=5.1
with optional parameter
GET https://dev.azure.com/{organization}/{project}/_apis/policy/configurations?scope={scope}&policyType={policyType}&api-version=5.1
You could check the templates below for different configurations in Policy template examples.
Examples
Approval count policy
Build policy
Example policy
Git case enforcement policy
Git maximum blob size policy
Merge strategy policy
Work item policy
If you still don't know how to compose the request body, you could also share your scenario.
i finally made it, it was very hard and i dont understand why Microsoft has so bad documentation.... i had to made it by sending randoms request and look at the elements how the names are... so bad so much time spend...
Related
Requirements: We would like to create a Variable Group (along with some variables) in a given Project.
Option1: We are able to create a new Variable Group successfully
when we create a request via PostMan using PAT Token which has FULL access.
Option2: Our end goal is to invoke the ADO Rest API in the Web App which uses
OAuth. When the end user logs in and make a call (pls see the input
details below) we are getting '401 Un Authorized - The user is not authorized to access this resource.' error. The Web App's application has the Variable Groups manage scope as shown below.
TroubleShooting: As part of troubleshooting, for Option1 which uses PAT (with full access) in Postman, we have updated the permissions of the PAT to just have Create, Read and Manage Var Groups as shown below.
Now, even the Option1 is not working after making the PAT to have Custom Defined access.
Are we missing something?
Postman Details:
URL: https://dev.azure.com/myorgname/_apis/distributedtask/variablegroups?api-version=6.0-preview.2
Verb: Post
Headers: Authorization: Basic
Body:
{
"name": "This is ignored",
"description": "This is ignored",
"type": "Vsts",
"variables": {
"BuildConfiguration": {
"value": "Release"
}
},
"variableGroupProjectReferences": [
{
"name": "VarGroup",
"description": "The variable group to store the information about the variables using in the Pipeline",
"projectReference": {
"id": "#ProjectId#",
"name": "#ProjectName#"
}
}
]
}
I can also reproduce your issue with option 1, not only Read, create, & manage for Variable Groups, even I select all the scopes via Custom defined, it still does not work.
According to this doc - https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/manage-pats-with-policies-for-administrators?view=azure-devops#restrict-creation-of-full-scoped-pats
Some of our public APIs are currently unassociated with a PAT scope, and can therefore only be used with “full-scoped” PATs. Because of this, restricting the creation of full-scoped PATs might block some workflows. We're working to identify and document the affected APIs and eventually associate them with the appropriate scope. For now, these workflows can be unblocked by using the allow list.
I believe this should be the reason for this issue, there may be some additional permissions to create variable groups. For option 2, there may be a similar cause.
So in this case, you may need to use the Full access PAT temporarily, as mentioned in the doc We're working to identify and document the affected APIs and eventually associate them with the appropriate scope.
I have the following resources in my system 1. Services 2. Features where a feature has the following JSON structure,
{
id: "featureName",
state: "active",
allowList: [serviceID1, serviceID2],
denyList: [serviceID3, serviceID4]
}
I am trying to update the allowList or denyList which consists of serviceIDs and thinking of using PATCH method to do it like below,
/features/{featureId}/allowlist
/features/{featureId}/denylist
/features/{featureName}/state/{state}
My first question is should I even include allowlist, state, denylist in the url as my resources are services and features, not the allowlist or denylist.
How should the rest endpoint look like?
After reading thread mentioned below I was thinking about restructuring urls as below,
/features/{featureId}
[
{ "op": "add", "path": "/allowList", "value": [ "serviceA", "serviceB"]},
{ "op": "update", "path": "/state", "value": false}
]
Lastly, the use of PATCH even justified here? or there is any better way to design the api.
Note: I have got some help from the thread REST design for update/add/delete item from a list of subresources but have not used patch often.
How should the rest endpoint look like?
The URI that you use to edit (PUT, PATCH) a resource should look the same as the URI that you use to read (GET) the resource. The motivation for this design is cache-invalidation; your successful writes automatically invalidate previously cached reads of the same resource (same URI).
Lastly, the use of PATCH even justified here? or there is any better way to design the api.
In this example, the representation of the document is small compared to the HTTP headers, and the size of your patch document is close to the size of the resource representation. If that's the typical case, I'd be inclined to use PUT rather than PATCH. PUT has idempotent semantics, which general purpose components can take advantage of (for example, automatically resending requests when the response to an earlier request has been lost on the network).
GET /features/1 by user1
PUT /features/1 //done by user 2
PUT /features/1 //done by user1
the PUT by user2 will not be visible for user1 and user1 will make an update on the old object's state (with id=1) what can be done in this situation?
Conditional Requests.
You arrange things such that (a) the GET request from the server includes validators that identify the representation (b) the server responds 428 Precondition Required when the request lacks conditional headers (c) the clients know to read the validators from the resource metadata, and use the correct condition headers when submitting the PUT request (d) the server knows to compare the validator to the current representation before accepting the new representation.
We're building a web based self service for our employees, to speed up/improve everyones DevOps experience. The self service utilizes the Azure Devops REST API and most of it works fine but as I'm about to implement the branch policies I get stuck for lack of documentation (or my inability to find it).
I think I have found what documentation is available for creating policy configurations, like this article. There's just a general mention of "settings" needs to be a JObject and then seven examples for various scenarios but if there are any reference articles for the 14 supported policy types then I have missed it.
Am I just blind or did Microsoft just not bother with documenting how to form the JObjects for the different kinds of configurations?
Azure Devops REST API documentation for policies is missing?
For me, I am more inclined that the document does not explicitly point out the content of JObject.
When we check that REST API document Configurations - Create, we could get following info:
Indeed, it only states that its type is a JSON object without specific content or examples.
To get the content of this JSON object, I use the REST API Configurations - Get to get the content of the Response body, I could get following response body:
"settings": {
"minimumApproverCount": 2,
"creatorVoteCounts": false,
"allowDownvotes": false,
"resetOnSourcePush": false,
"requireVoteOnLastIteration": false,
"resetRejectionsOnSourcePush": false,
"blockLastPusherVote": false,
"scope": [
{
"refName": "refs/heads/Dev",
"matchKind": "Exact",
"repositoryId": "dcb40ef6-dae0-4e3c-b581-2f71c76e09a6"
}
]
},
So, we could to know the content is indeed a JSON object and it will be different due to the different policies we set.
Now, we move back to the samples in that document, we could find that there are many such settings, like:
Approval count policy:
{
"isEnabled": true,
"isBlocking": false,
"type": {
"id": "fa4e907d-c16b-4a4c-9dfa-4906e5d171dd"
},
"settings": {
"minimumApproverCount": 1,
"creatorVoteCounts": false,
"scope": [
{
"repositoryId": null,
"refName": "refs/heads/master",
"matchKind": "exact"
}
]
}
}
If we want to set any other supported policy types, we can manually set it on the UI, and then get the corresponding response body about it.
I am trying to create an API that logs JSON request bodies in an SQS queue.
I have set up a basic queue in SQS in both the FIFO and non-FIFO layouts. I have the same problem each time. My policy for the SQS queue is as follows:
{
"Version": "2012-10-17",
"Id": "arn:aws:sqs:us-east-1:2222222222222:API-toSQS.fifo/SQSDefaultPolicy",
"Statement": [
{
"Sid": "Sid22222222222",
"Effect": "Allow",
"Principal": "*",
"Action": "SQS:*",
"Resource": "arn:aws:sqs:us-east-1:2222222222222:API-toSQS.fifo"
}
]
}
I have created a policy which i give all access to SQS for writing abilities. And I have created a role for API Gateway in which i assign the aforementioned policy to. Here is the policy i have assigned to this role:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"sqs:DeleteMessage",
"sqs:ChangeMessageVisibility",
"sqs:DeleteMessageBatch",
"sqs:SendMessageBatch",
"sqs:PurgeQueue",
"sqs:DeleteQueue",
"sqs:SendMessage",
"sqs:CreateQueue",
"sqs:ChangeMessageVisibilityBatch",
"sqs:SetQueueAttributes"
],
"Resource": "*"
}
]
}
I have set up an API gateway. I have created a POST method. I've tried enabling the CORS option (which create an OPTIONS method) and i've done it without CORS enabled. My ARN for my security policy is correct, i have triple checked it. and i opt for the override path and have the full https URL of my SQS queue there, i have triple checked this as well. My endpoint is SQS of course.
For integration request i have a HTTP header for Content-Type and then a Mapped From as 'application/x-www-form-urlencoded'
in mapping templates i have passthrough set as never and have a Content-Type set to application/json is also have included the template Action=SendMessage&MessageBody=$input.body to translate from body to url as per a walkthrough i found.
i am getting the following error in the API Gateway test area
<AccessDeniedException>
<Message>Unable to determine service/operation name to be authorized</Message>
</AccessDeniedException>
Is there a AWS guru out there who can steer me in the right direction?
to clarify my issue is that it should be adding my test body
{"peanutbutter":"jelly"}
to the SQS queue, but no luck.
I can send url encoded messages to SQS all day from postman, but i want my business partners to be able to send a clean JSON object via http (postman, node, etc, whatever..)
thank you!
i opt for the override path and have the full https URL of my SQS queue there
In Path Override type only path part of SQS queue URL 2222222222222/API-toSQS.fifo.
Also, MessageGroupId is required for fifo queues and if ContentBasedDeduplication is not enabled MessageDeduplicationId is required too.
Example of mapping template:
Action=SendMessage&MessageGroupId=$input.params('MessageGroupId')&MessageDeduplicationId=$input.params('MessageDeduplicationId')&MessageBody=$input.body
in this case you need to define MessageGroupId and MessageDeduplicationId as required query string parameters in Method Request and obviously pass them on requests to the API endpoint.
For anyone having this same issue, removing all of the settings from the integration request in API Gateway and using Lambda as a "middleman" worked. Lambda is a great go-between for almost all of the AWS services. I would prefer to have a API Gateway -> SQS stack instead of using API Gateway -> Lambda -> SQS, but for whatever reason the way the lambda handles the HTTP request as opposed to trying to configure API Gateway to do the same, works without issue.
you will not need any external resources in Lambda, so no importing Zip files. Just import AWS and SQS. use the basic structure to accept the event, then take the body (as JSON in my case) and sqs.sendMessage to your queue.
hope this helps anyone with the same issue.
I'm trying to batch update a bunch of existing records through Marketo's REST API. According to the documentation, the Import Lead function seems to be ideal for this.
In short, I'm getting the error "610 Resource Not Found" upon using the curl sample from the documentation. Here are some steps I've taken.
Fetching the auth_token is not a problem:
$ curl "https://<identity_path>/identity/oauth/token?
grant_type=client_credentials&client_id=<my_client_id>
&client_secret=<my_client_secret>"
Proving the token is valid, fetching a single lead isn't a problem as well:
# Fetch the record - outputs just fine
$ curl "https://<rest_path>/rest/v1/lead/1.json?access_token=<access_token>"
# output:
{
"requestId": "ab9d#12345abc45",
"result": [
{
"id": 1,
"updatedAt": "2014-09-18T13:00:00+0000",
"lastName": "Potter",
"email": "harry#hogwartz.co.uk",
"createdAt": "2014-09-18T12:00:00+0000",
"firstName": "Harry"
}
],
"success": true
}
Now here's the pain, when I try to upload a CSV file using the Import Lead function. Like so:
# "Import Lead" function
$ curl -i -F format=csv -F file=#test.csv -F access_token=<access_token>
"https://<rest_path>/rest/bulk/v1/leads.json"
# results in the following error
{
"requestId": "f2b6#14888a7385a",
"success": false,
"errors": [
{
"code": "610",
"message": "Requested resource not found"
}
]
}
The error codes documentation only states Requested resource not found, nothing else. So my question is: what is causing the 610 error code - and how can I fix it?
Further steps I've tried, with no success:
Placing the access_token as url parameter (e.g. appending '?access_token=xxx' to the url), with no effect.
Stripping down the CSV (yes, it's comma seperated) to a bare minimum (e.g. only fields 'id' and 'lastName')
Looked at the question Marketo API and Python, Post request failing
Verified that the CSV doesn't have some funky line endings
I have no idea if there are specific requirements for the CSV file, like column orders, though...
Any tips or suggestions?
Error code 610 can represent something akin to a '404' for urls under the REST endpoint, i.e. your rest_path. I'm guessing this is why you are getting that '404': Marketo's docs show REST paths as starting with '/rest', yet their rest endpoint ends with /rest, so if you follow their directions you get an url like, xxxx.mktorest.com/rest/rest/v1/lead/..., i.e. with '/rest' twice. This is not correct. Your url must have only one 'rest/'.
I went through the same trouble, just want to share some points that help resolve my problem.
Bulk API endpoints are not prefixed with ‘/rest’ like other endpoints.
Bulk Import uses the same permissions model as the Marketo REST API and does not require any additional special permissions in order to use, though specific permissions are required for each set of endpoints.
As #Ethan Herdrick suggested, the endpoints in the documentation are sometimes prefixed with an extra /rest, make sure to remove that.
If you're a beginner and need step-by-step instructions to set up permissions for Marketo REST API: Quick Start Guide for Marketo REST API