As far as I checked on many swagger files of Amazon/Google and more, That error code (or generally error codes of 5xx family) is not shown as a part of the swagger files. Is their a reason for that?
I am asking because one of our microservices API returns 500 when it fails to communicate to other service (for instance) and we are wondering if that error code should be part of our swagger files.
Generally clients/consumers can't do much upon getting the 5xx errors, since those are purely server side errors. So it need not to be part of your API specification.
If you think, based on the error which the API throws, client/consumer should do something (For example retry or try another site or so.), then Yes.
I think API documentation should only contain expected errors such as 4xx ones. But 5xx are unexpected errors and should not be documented.
Related
I have a strange problem whereby any REST APIs relating to SharePoint versions work when testing at design time but generate a 403 Forbidden error at runtime. What is also odd is that all other REST API calls work fine at both design time and runtime and all the parameters are identical to the ones that don't work (headers etc.) and I've done a cut and paste on everything, but still anything relating to versions isn't working, although that might just be a red herring?
The app can successfully delete files and overwrite them, check in and out, etc. so seemingly there are no permission issues. I have also tried checking a file out before reading the version information just in case (as check out is forced before any actions can be carried out on this site) but that didn't work either.
This is an example of one of the calls that is causing the error:
https://mycompany.SharePoint.com/sites/{SiteName}/_api/web/GetFileByServerRelativeUrl('/sites/{SiteName}/Shared%20Documents/{FilenameAndPath}')/version
Look at this post:
https://sharepoint/_api/web/folders/getbyurl('Documents')/files/getbyurl('myfile.docx')/versions?$filter=VersionLabel eq '2.0'
Check the Accept and Content-Type headers in the OnBeforeRequest REST API callback.
I have found that when testing the IDE will send for instance "application/json" for both, but at runtime, the platform adds ";utf-8" to the values of these headers. The requests are then often rejected without a proper error specification/declaration.
Even after reading many documents, books, spec
I couldn't 100% be certain whether I should use http status code 403 or 409 in my case.
Some argue that 403 should be used only with an authorization issue, but seeing twitter's api using 403 for update limits violation, I think 403 actual use is broader than just authorization issues. Maybe it can be used to tell a request has violated a server-side constraint.
And, from the spec, 409 seems to be used when we can expect that client can resolve the issue.
I'd appreciate some variety of real world examples of when to use 403 and when to use 409, and for an opinion on which code to use in my case, which I will lay out in the abstract below (so as not to violate NDA).
After edit: The example is lengthy but, simply put, it is about what code to return when constraint validation fails. Do you always return 400 when constraint validation fails? Should I return 400 and not 403 or 409?
There is a client that tells service A which shelf contains a specific book. While recording to the DB which book is on which shelf, service A is able to tell the client that the client is trying to put the book in a wrong shelf. Service A can tell this by asking another service B that basically has some logic in deciding where a book should go to.
What http code should service A use in this case?
(The request conflicts with service B's decision -- 409? -- but the client is not able to resolve this problem because when service B makes a decision it is permanent. And book id and bookshelf id is both in the path parameter (ie, they are the only parameters in this endpoint) so the client can't really make any change to resolve the issue with the same request)
Additionally, the client is able to tell service A that a bookshelf should no longer be used (because it is full or for whatever reason). When the client tells service A that bookshelf C is not in use anymore, and then later the client tells service A that it wants to put another book on bookshelf C, service A should tell the client that it can't do that. What http code should service A use in this case? (The request will conflict the database status that says bookshelf C is not in use -- 409? But client is not able to resolve this problem because when a bookshelf is not in use, it is permanent in service A and it is never in use again -- not 409?)
Thank you in advance for your time and input!
Of the two codes mentioned, HTTP 403 is far more common and describes a valid (but unauthorized) request
HTTP 409 is not very common. It describes a conflict (like a deadlock or some other type of issue) that resulted in an error. I think Mozilla gives good advice when it describes this error most commonly occurring with with the PUT verb.
For a broader error condition, I would recommend using a 500 error code
I want to debug the Rest API service project with visual studio 2017.I use breakpoints , the breakpoints becomes yellow at catch exception when I hover my mouse over the e.message but I can not see the error message, also I can not see the error with Debug.Writeline in output window .
When you want to debug an API, it is not the IDE that matters. You need to think of the full flow of the API invocation. If someone is complaining that an API is not working, then you need to divide and conquer the problem. The article on debugging API driven applications detail the layers you need to be aware of. You need to consider
Client application
Client to API connection
API logic
API to database connection
Speed of API and client applications
In simple terms, if you want to see if only the API implementation works, see if there is a response for the request being sent to the API. Then check the logic. Then check the connection to database, and so on ...
I'm making some REST services, and as I'm implementing a GET request, I was debating about what I should do if there is no record there, for example /profile/1234. Now, if you tried to use /profiles/1234 (note the s on profiles) it would definitely be a 404 code because that URL definitely isn't found. But when it comes to there just being no 1234 profile, I'm not sure what I should return. I don't want to return {} because that might give the impression there is a record with no data. But if I return a 404 error code, how is the consumer of the API supposed to tell the difference between the two 404s?
How can I be a responsible API designer by communicating programmatically what the difference between a service that doesn't exist and a record that doesn't exist?
You can send a custom status message which will help you differentiate between the "different" 404s.
On the other hand, I wouldn't worry about that distinction. People are used to having to type api endpoints carefully. As long as they manually test their app a tiny bit the issue becomes a non-issue.
First time posting a question. I'm trying to call some SOAP webservices from inside a blackberry app using the ksoap2 library. I've successfully managed to get a response from the one service, which uses an HTTP url, but now that I'm trying to get response from a (different) HTTPS url, I've run up against a brick wall.
The response dump I'm getting has the following fault message:
"An error occurred while routing the message for element value : (country option I specified in my request). Keep-Alive and Close may not be set using this property. Parameter name: value."
The weird thing is that using Oxygen XML's SOAP tools with the XML request dump works just fine. Any ideas where to start looking? This has taken up a full day already.
Update:
Responding to your comment below - it turns out the double quoting is part of the SOAP spec. Some servers are more relaxed in their implementation, and will work without the quotes.
ksoap2 doesn't force the quotes onto your actions - you may want to patch your ksoap2 library to ensure the quotes are always there.
ymmv
Original:
I don't think this is a SOAP related problem, nor with BlackBerry.
I think the problem lies on the server side, since that error string is not a common error (just google it to see no hits on the whole internet other than this question).
Looks like this is a job for the network guy on the server side to tell you what he's seeing on his end.
Only other thing I can think of is to make the call using HTTP instead of HTTPS. You can then use some network sniffer to see what the difference between the messages is. Alternatively, install an SSL proxy with something like "Charles" and sniff the packets like that.