I need to add a signature to my request before it is tested. Hence before Pact testing happens on provider side, i need to add a signature which is generated based on the entire request. Is there a way to get the request before Pact Verification happens, so i can generate and add the signature ?
PS: I already added some other headers using CustomHeaders. But i need the request itself to generate the signature. This is for C#
TL;DR
Is there a way to add an extra custom parameter text-box in the authorization like so?
On client authorization, I have a custom token request validator, ICustomTokenRequestValidator which checks some for some extra info in the request's context. When I do the requests through postman I can have these parameters inside the request (form-data etc) and I can get the required extra parameter and do my custom validation.
I didn't find a way to do this through swagger, is there a way to add a parameter (custom text box) when I want to make a request for authorization?
Provider side matching is not working if I add any thing or rename or remove any field in request body of provider which is not same as contract then its not failing.
Eg inside contract file request body contain name field and the same field if I remove or rename in request body of provider (not in response) only in request then pact is not validating that.
I want to confirm at provider side will the matching work on request body?
I can see matching rule for request body in pact file but its seems like not functioning.
Adding new fields into a provider response that is not required by a Pact contract is simply ignored.
Why is this the case? Pact follows Postel's Law. Unexpected elements in a response should not cause issues for a consumer. Other consumers may have different but overlapping needs, so failing a provider build on these grounds is problematic.
From our docs, what this translates to:
Be conservative in what you send - when the mock server in the consumer project compares the actual request with the expected request, the actual request body is not allowed to contain fields that are not defined in the expected request body. We don't want the situation where our real consumer is "leaking" data that we don't know about.
Be liberal in what you accept - when verifying a pact in the provider project, the response body and headers may contain fields that were not defined in the expectations, on the assumption that any extra field will be ignored by your consumer. This allows a provider to evolve without breaking existing consumers (unlike the bad old WSDL days).
To your second point:
I want to confirm at provider side will the matching work on request body?
It sounds like it is working. It's correctly identifying breaking changes if you change the datatype, or have an unexpected response code.
If you rename a field that is required by a consumer, then that sounds like a bug (a fatal one in terms of Pact features, so I'm skeptical).
My users enter a few information fields in an iOS app.
This information must be validated on my server, which has a RESTful API.
After validation the UI of the iOS app changes to indicate the result.
Neither GET, PUT, or POST seem to be appropriate, because I'm not getting a resource, and neither is a resource created or updated.
What is the best fitting REST operation to implement this validation?
I use the same scenario as you and use PUT for it. You have to ask yourself: "when I send the same request twice, does this make a different state on server?" If yes, use POST, if no use PUT.
My users enter a few information fields in a iOS app. This information
must be validated on my server, which has a RESTful API. After
validation the UI of the iOS app changes to indicate the result....I'm
not getting a resource, and neither is a resource created or updated.
Since you aren't saving anything (not modifying any resource), I'd think this is technically more RPC than RESTful to me.
The following is my opinion, so don't take it as gospel:
If the information is simply being submitted and you're saying yes or no, and you're not saving it, I'd say POST is fine..
If information were actually being saved / updated, then choosing the proper HTTP method would be a lot more relevant.
POST = CREATE / SUBMIT (in an RPC context)
PUT = UPDATE (or CREATE if there is nothing to UPDATE)
I recommend using a ValidationResource and two requests. Each instance of this resource represents the validation of a set of data. The workflow:
1. Create new ValidationResource
Request: POST /path/to/validations
data to validate as the body
Response: 201 Created
Location: /path/to/validations/<unique-id-of-this-validation>
2. Look up result
Request: GET /path/to/validations/<unique-id-of-this-validation>
Respons: 200 OK
body: {'valid': true} or {'valid': false}
This is a RESTful approach in which the Validation is a Resource with server state.
Google proposes use of Custom Methods for REST API
For custom methods, they should use the following generic HTTP
mapping:
https://service.name/v1/some/resource/name:customVerb
The reason to use : instead of / to separate the custom verb from the
resource name is to support arbitrary paths. For example, undelete a
file can map to POST /files/a/long/file/name:undelete
Source: https://cloud.google.com/apis/design/custom_methods
So for validation the URL should be POST /resource:validate
I believe it is similar to GET entity but since we need to send data to validate and sending confidential data in URL is wrong habit as only payload data is ciphered by TLS, the only way left is POST or PUT.
However you may save or update the data in validate(eg. "verified":false). Based on requirement, you can go for POST or PUT (recommended POST if no update)
POST /user/validate-something
It seems like you're not doing it the correct way, if the validation is at the server-side then it should happen while submitting the data using a POST method. Then you'll validate that data, if validation fails then you can raise a 400 BAD REQUEST error, else you can create the resource.
This approach is more RESTful, as the POST method is properly used to create a resource or to raise 400 if validation fails
when we are calling dynamodb with http rest api it is giving this error
Can i know what is the problem? what are all the required things we need to append in the dynamodb url??
http://dynamodb.us-east-1.amazonaws.com/?aws_access_key=XXXXXXXXXXXXXXXX&aws_secret_access_key=ZZZZZZZZZZZZZZZZZZZZZZ
Do we need to append anything more parameters with this url please let me know??
http://docs.amazonwebservices.com/amazondynamodb/latest/developerguide/UsingJSON.html#JSONMajorExample
Your solution is in the same link
http://docs.amazonwebservices.com/amazondynamodb/latest/developerguide/MakingHTTPRequests.html
If you don't use one of the AWS SDKs, you can perform Amazon DynamoDB operations over HTTP using the POST request method. The POST method requires you to specify the operation in the header of the request and provide the data for the operation in JSON format in the body of the request.
You need to make POST request with all the required parameters mentioned in that page.