I'm using an openapi specification, which configures AWS gateway. I'm also using request validation. It works fine with informative error messages if I print out $context.error.validationErrorString in case of 4xx error messages. (In case of missing request data, It will write out exactly which request data is missing)
In case of using multiple schemas for an endpoint in the openapi spec (with using oneOf), validation also works, but the error message does not contain specific message, just that schema matching was not succesfull [instance failed to match exactly one schema (matched 0 out of 1)
I think the problem is that schema validation happens first, so api gw throws this error first. Is there any possibility to find out what is the exact request validation error in this way, so maybe fore api gw to run also the request validation?
Confirmed with AWS support that this is not possible at the moment.
Related
I have a AWS Lambda Pipeline that makes API calls to the Purview API and has been working fine until yesterday.
The error occasionally I get is as below:
{'requestId': 'xxxxxx-xxxx-xxxx-xxxxxx', 'errorCode': 'PreConditionCheckFailed', 'errorMessage': 'Pre-condition check failed. Please fetch latest data from Catalog service and update again. Conflict object ID: xxxxx-xxxxx-xxxx-xxxxxxx'}
Some additional info:
From some googling, I understand that this might be an error that is described to only pop up from any other API requests other than GET, so not sure why I'm getting this here when I'm only using GET requests
the API endpoint is: https://learn.microsoft.com/en-us/rest/api/purview/catalogdataplane/entity/get-by-guid
the API call returns the error when I try to use a GUID for a table's column. But, in the error, the 'conflict object ID' is the GUID for the table
I rescanned data sources and assets, replaced collections in Purview but still get the same error
Anyone have any ideas why?
I have looked at many posts about how to accept an uploaded document in a WCF service REST endpoint. They say you should define the endpoint to have a single parameter with type Stream. Here is an example of one. I have implemented it as they suggest and it does work. Here it is in VB:
<OperationContract()>
<WebInvoke(Method:="POST", BodyStyle:=WebMessageBodyStyle.Bare)>
Function UploadDocument(data As Stream) As Stream
However, I am working with the additional constraint that this WCF service also uses SOAP endpoints. After adding this REST endpoint that accepts a Stream, the SOAP endpoints are breaking. The error in the SOAP response says
System.InvalidOperationException: For request in operation UploadDocument to be a stream the operation must have a single parameter whose type is Stream.
I am amazed that adding a REST endpoint would break these SOAP endpoints, but perhaps this would be more obvious for someone with experience in SOAP (I am new to it, as well as WCF Services). I looked that error up and found this post. This comment from Drew Marsh seems to be the fundamental problem here:
the WSDL generator implementation is made for the SOAP/RPC service contracts and on those you can't either have individual parameters of various intrinsic or data contract types, a Stream or a message contract. You can't mix the three together. So, when it tries to generate metadata for your REST service contract, where it's perfectly valid to throw a Stream parameter in the mix as the last parameter for the body, it bombs out with the error your seeing because it never expects to come across a signature like that.
I do not see any solution on that post or anywhere else I search. I tried making a <DataContract> class which has the document as a property with type Stream, along with the other form fields as properties, but when I try that I get the error
Unhandled InvalidOperationException in service: The incoming message has an unexpected message format 'Raw'. The expected message formats for the operation are 'Xml', 'Json'. This can be because a WebContentTypeMapper has not been configured on the binding. See the documentation of WebContentTypeMapper for more details.
Am I simply SOL if I want this REST endpoint to accept a multipart/form-data body? Or is there some way to make this work with all the constraints I'm working with? In case it makes a difference, yet another constraint is that this service is stuck in .NET 4.0, so that rules out some potential libraries that need .NET 4.5.
I am designing a REST API for registering enrollments to classes. In my of my endpoints, I can POST an enrollment:
POST to http://my-api/class/learn-rest/enrollment
This creates a new enrollment. However, in this case, there can only be a fixed number of enrollments, let's say 5.
Which HTTP response code should I return when the user tries to add the 6th enrollment?
Good question. Not sure why it's down-voted.
I'd suggest 400. It's the one you should use if you can't find a specific and appropriate status code for your 4xx errors.
409: it's inappropriate because it's usually retriable. But certainly retrying in your case would resolve the problem.
429: it's also retriable.
Did more research (some practices used by well-known api providers)
LimitExceededException: Returned if the request results in one of the following limits being exceeded, a vault limit, a tags limit, or the provisioned capacity limit. 400 Bad Request
https://docs.aws.amazon.com/amazonglacier/latest/dev/api-error-responses.html
Unless a more specific error status is appropriate for the given request, services SHOULD return "400 Bad Request" and an error payload conforming to the error response guidance provided in the Microsoft REST API Guidelines.
https://github.com/Microsoft/api-guidelines/blob/vNext/Guidelines.md#1521-error-response
While suggesting some specific HTTP code may be an opinion based answer, there is one things that you should keep in mind - this is should be a 4xx Client error:
4xx Client errors: This class of status code is intended for situations in which the error seems to have been caused by the client.
Among existing errors, the following looks like the most suitable for you:
409 Conflict: Indicates that the request could not be processed because of conflict in the request, such as an edit conflict between multiple simultaneous updates.
I think so cause there is a next possible scenario: let's say you set 5 as the limit of enrollments, 4 already exist in system and server receives 2 requests at the same time to create a new enrollment. In this case, only one of the requests (the first one for server) is OK.
What's the best HTTP status code to use in response to an HTTP GET for a resource that's corrupt or semantically invalid?
E.g., consider a request to GET /person/1234 where data for person ID 1234 exists on the server but violates some business rule, so the server refuses to use it.
404 doesn't apply (because the data actually exists).
4xx in general seems not ideal (because the problem is on the server end, not under the client's control).
503 seems to apply to the service as a whole, not a particular resource.
500 certainly fits, but it's very vague in actually telling the client what might be wrong.
Any suggestions?
After reading the comments and the linked resources, it looks like #RemyLebeau's approach is best:
I think 500 is the only official response code that fits this situation. And there is nothing stopping you from including a response body that describes the reason for the failure.
according to iana.org:
4xx: Client Error - The request contains bad syntax or cannot be fulfilled
5xx: Server Error - The server failed to fulfill an apparently valid request
I think none of the 4xx status code should be valid as a response to an internal server error or migration or ... where client has no responsibilities or where user's inputs are expected to be rechecked. unless user's pre-filled data are involved like maybe user's package is not allowing him to access that data after a pre-determinate and known date, in such specific case It may be valid a 403 Forbidden as #Bari did suggest.
I'm not an expert but I think when the rejection or the decision of considering endpoint data as corrupt or invalid is made by server, then it will depends on what should be done next. I see 3 possible cases:
1. It is expected that somehow this is going to be fixed and client
should be invited to request it back but at some future moment ==> 503 (Service Unavailable):
503 (Service Unavailable)
status code indicates that the server
is currently unable to handle the request due to a temporary overload
or scheduled maintenance, which will likely be alleviated after some
delay. The server MAY send a Retry-After header field
(Section 7.1.3) to suggest an appropriate amount of time for the
client to wait before retrying the request.
2. Something is wrong, it is not client responsibility but there is an alternative way to access data, maybe following a specific process or sending further details ==> 510 Not Extended
2. Server cannot fulfill the request but there is an alternative way that requires it to include further details. Example: when requested data is corrupt, server error response may include a list of older (or unsaved, unversioned) versions of it and expect client to be more specific about which version to select so it could be fetched instead of the corrupted one ==> 510 Not Extended
510 Not Extended
The policy for accessing the resource has not been met in the
request. The server should send back all the information necessary
for the client to issue an extended request. It is outside the scope
of this specification to specify how the extensions inform the
client.
If the 510 response contains information about extensions that were
not present in the initial request then the client MAY repeat the
request if it has reason to believe it can fulfill the extension
policy by modifying the request according to the information provided
in the 510 response. Otherwise the client MAY present any entity
included in the 510 response to the user, since that entity may
include relevant diagnostic information.
case 2 was updated to include an example as IMHO it may fit in such case. but again I'm not any expert and I may be
wrong about it
3. No alternative ways, nothing to be expected or none of the other cases ==> 500 should be good
500 (Internal Server Error)
status code indicates that the server
encountered an unexpected condition that prevented it from fulfilling
the request.
My rest service method demands an input parameter. I want to see data structure via postman. How can I add arguments in postman app? I get the error:
HTTP Status 500 - The bean encountered a non-application exception;
nested exception is: The server encountered an internal error that
prevented it from fulfilling this request.
Suppose that you are doing a POST, or a PUT, you want to add your data in XML or JSON or plaintext to the request.
You need to set the URL, and the right HTTP method. Once you choose, suppose POST, you can edit the data to be sent. I choose the raw input type and write inside it what I want to send to the server.
You may get 500 as server error due to error in the logic of the offered service, try to encapsulate your entity and send agin the request..