To delete an existing module the documentation (http://cumulocity.com/guides/reference/real-time-statements/) says to do a DELETE request against /cep/module/<<moduleId>>. But this results in a response status 500 with the reason that "Request method 'DELETE' not supported".
What is the correct request to delete a single module?
The documentation gives the wrong path. It needs to be /cep/modules/<<moduleId>> instead of /cep/module/<<moduleId>>. This can be seen by debugging the behaviour of the web-GUI.
Related
I have a quiz in which I can give an answer to a question over a restful API. The request will transmit the answer to the question over a PUT-Request to an URL like “/question/{id}/answer”. But each question can only be answered once. The answer can be queried over a get request but can never be changed again. What HTTP Error Code do I return when the client tries to change the immutable answer with a PUT request?
I tried this error codes:
405 Method Not Allowed: But in the first place a PUT is fine. But once the object is set a PUT is not allowed anymore. Is it OK if the list of allowed methods change over time?
409 Conflict: Would work, but the RfC says “his code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request.” And here the client would not be able to resolve the conflict.
400 Bad Request: It is in general a bad request but not “due to malformed syntax.”
So, is it a Server Error (5xx)? In case of a 500 Internal Server Error the RfC states that “The server encountered an unexpected condition”. But we expect the object to become immutable at some point.
Is it OK if the list of allowed methods change over time?
Yes.
Allow header field in a 405 response containing a list of the target resource's currently supported methods. -- RFC 7231
Note: currently supported methods....
I am calling a REST API for a list of resources and getting the json response as below if atleast one resource is there.
{
"value": [
"res1_id",
"res2_id",
"res3_id"
]
}
and the HTTP response code is 200.
But when no resource is there the server is returning HTTP response code as 404.
My doubt it why it is designed that way(it is an enterprise product).
I was expecting a empty list as below and HTTP response code 200:
{
"value": []
}
I am not able to understand what design decision has been taken into consideration to return 404 instead of an empty json.
Please help me to understand the reasoning behind it.
What I am reading here is that you have a 'collection' resource. This collection resource contains a list of sub-resources.
There's two possible interpretations for this case.
The collection resource is 0-length.
The collection resource doesn't exist.
Most API's will treat a 0-length collection as a resource that still exists, with a 200 OK. An empty coffee cup is still a coffee cup. The coffee cup itself did not disappear after the last drop is gone.
There are cases where it might be desirable for a collection resource to 404. For example, if you want to indicate that a collection never existed or never has been created.
One way to think about this is the difference between an empty directory or a directory not existing. Both cases can 'tell' the developer something else.
You're trying to access a resource which does not exist. That's the reason for 404.
As a simple google search says
The HTTP 404, 404 Not Found, and 404 error message is a Hypertext
Transfer Protocol (HTTP) standard response code, in computer network
communications, to indicate that the client was able to communicate
with a given server, but the server could not find what was requested.
For your case
{
"value": []
}
This can be a status code 200 which means the resource is accessed and data is returned which is an empty array or you can customize it to a 404. But for that you've mentioned best is to return 200.
A status code of 404 is the correct response for when there is no resource to return based on a request you made. You asked for data and there is no data. It returns an empty response. They're relying on you to base your interpretation of the results on the status code.
https://en.wikipedia.org/wiki/HTTP_404
Some companies prefer making their errors known instead of hiding them. I know where I work we shy away from try catch blocks because we want our applications to blow up during testing so we can fix the problem. Not hide it. So it's possible that the dev that created the API wants you to use the status code of the response as a way of telling if the service was successful.
If a Restful webservice fails to update or create a resource with PUT or POST methods respectively, what should be the response code?
Should the response code for failure of PUT and POST methods be in the 200 or 500 range. And what should be the exact code and possible response message.
Edit: extending the question to GET and DELETE also
And similarly what should be the failure code for unsuccessful GET and DELETE requests.
Ex: GET /profiles/lincoln - refers to existing profile - so returns 200 response code(correct me if wrong).
but GET /profiles/mccain - refers to not existing profiles - so what should be response code
And similarly for delete -
Ex: DELETE /movies/starwars - refer to existing movie so delete is successful (not sure what the success response code should be for delete - plz comment)
but: DELETE /movies/planetofhumans - refers to non - existing movie. so what should be the response code.
Stop making it hard.
The semantics are described in RFC 7231
if the request contains bad syntax or cannot be fulfilled: return a status from the 4xx (Client Error) class
if the server failed to fulfill an apparently valid request: return a status from the 5xx (Server Error) class
The actual method specified in the request doesn't matter: they all use the same semantics for each of the status codes.
Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition.
You can use any media type you like for that representation - web sites have been using HTML for years. If you are looking for something JSON specific, then Problem Details for HTTP APIs may be a good choice.
GET /profiles/mccain - refers to not existing profiles - so what should be response code
404 NOT FOUND
The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists.
I'm getting rejected only on the accountSummaries/list management call, everything else works fine - heck, it works even when executing it from the reference page! I double checked that the account being used was correct and, as I said, I have no issues performing the simple accounts/list call.
I'm using the python library, and for both of those calls no parameters are needed (so the chance of some embarrassing error are very low).
Basically I'm simply getting the service client and performing the simplest possible call:
a = client.AnalyticsManagementClient() # super simple wrapper
a._service.management().accounts().list().execute()
a._service.management().accountSummaries().list().execute()
The first call works fine, the second one returns a 403 error. Anyone have an idea why that might happen?
Full error is HttpError: <HttpError 403 when requesting https://www.googleapis.com/analytics/v3/management/accountSummaries?alt=json returned "Insufficient Permission">
It was just a scope issue: accounts needs at least one among
https://www.googleapis.com/auth/analytics
https://www.googleapis.com/auth/analytics.edit
https://www.googleapis.com/auth/analytics.readonly
while accountSummaries allows only the last two; it seems to be the only one that does not work with the analytics scope, which is the one our client was requesting.
I am writing JSON-RPC code to talk to the Zabbix API.
I have noticed that if I omit the "id" from the request, I get back a response with zero-length content. If I specify any "id" value, the content is a JSON object as documented in the API documentation.
Can I assume that if I provide "id" that I will always get back JSON describing the error if an error occurs, but otherwise I will get back a zero-length content and a status of 200 to document the success? I always want to know about errors, but for successful operations (like deleting something) it often will suffice to know that it succeeded.
Is this a general rule? Is it documented anywhere? If so, please tell me where.
According to the JSON-RPC 2.0 documentation, "A Notification is a Request object without an "id" member." The documentation goes on to state: "Notifications are not confirmable by definition, since they do not have a Response object to be returned. As such, the Client would not be aware of any errors (like e.g. "Invalid params","Internal error")."
So, if you omit the "id" it will never return an error, because it is a notification. For use with Zabbix, you should probably just stick to using an id. That way you can get verification and error messages.