Everyone loves REST-fulness, so I'd like to return the most appropriate HTTP status codes from my AppEngine endpoints. Like 201 CREATED, for example, when a resource has been created.
But I can't find how to do this with GAE Java endpoints.
Some 4xx codes are supported by throwing an exception (NotFoundException causes a 404, for example), but that's not an appropriate solution for 2xx codes.
Can anyone help please?
Matthew
Cloud Endpoints does support creating your own Custom Exception classes by subclassing com.google.api.server.spi.ServiceException
However, from the documentation at https://developers.google.com/appengine/docs/java/endpoints/exceptions , it is mentioned that HTTP 2xx codes should not be used in custom exception classes.
Related
I'm trying to run a simple test with Apache Camel:
from("http://localhost:61554/api/v1/MyController/my-endpoint")
.to("direct:a")
.log("$({body}");
I'm getting the following error: "No endpoint could be found for: http://localhost:61554/api/v1/MyController/my-endpoint, please check your classpath contains the needed Camel component jar"
I'm very new to Camel and Java. Can someone please tell me why this error is coming up? Should I be using from("direct:x")... ? If, so where do I map my "direct" endpoints to concrete ones?
Thanks
You cannot use the http component as consumer (eg in from) - its a http client for calling HTTP servers (so its a producer, eg to).
Instead to have HTTP as consumer you can use camel-servlet, camel-jetty, camel-undertow, etc.
I'm trying to handle error responses returned from the Google Cloud Pub/Sub api using their node client library. From what I can see, if you use their REST API directly (ie. not through the client library) they return common HTTP error codes:
https://cloud.google.com/pubsub/docs/reference/error-codes
However, their client library returns RPC style errors that do not adhere to http status code conventions.
I have a worker that is processing these responses and is expecting responses to conform to standard http response conventions. Does anyone know if there is a way to intercept the actual HTTP response that the client is handling and extract a status code from it? Alternatively, is there documentation somewhere listing out the potential RPC errors the node client can return so I can set up a mapping from them to http codes?
Thanks!
FYI this got answered as a Github issue here: https://github.com/GoogleCloudPlatform/google-cloud-node/issues/2761#issuecomment-348358474
Alright, first of all, I am absolutely aware that we have a bunch of answers on this and there is a plethora of articles on the topic. I just read these answers a second before typing this:
Why is CORS without credentials forbidden?.
Is CORS considered bad practice?
Etc. My particular situation is this - I just set up WebAPI2 for my practice project, the front end for which is running via gulp browser-sync. I have no idea how these ports get picked, but lets say the Web API is running on port http://localhost:1234/ and browser-sync generates the website on http://localhost:4321/. So I hit the API via angular's $http and get the famous CORS error (API controller method does get hit), so I am guessing it's the API returning not allowed. Edit: I fixed this via installing a CORS for Web API package via NuGet (Article Here) before asking this Q, just referencing for anyone who might need it later.
So, I was thinking, if I deployed this, ANY request would get denied, unless I am missing something. Or would it not be denied because of something I don't understand? Is disallowing CORS just a throwback from the MVC days? Or is there some purpose to it with APIs?
Maybe I am just ranting, but this confuses the **** out of me.
CORS is based on the response headers returned from the API. It is not the API that rejects responding to the request, the web browser explicitly disallows handling the response. The API will process the request as normal.
When dealing with anything other than a GET, CORS also requires a "preflight" request to the API first, to ensure subsequent requests are allowed. This amongst sending the headers back is what the Web API nuget package provides.
CORS is off by default for security purposes.
When calling a web service from Force.com, I am getting:
System.CalloutException: Web service callout failed: Unexpected
element. Parser was expecting element
'http://schemas.xmlsoap.org/soap/envelope/:Envelope' but found ':HTML'
The network guys at the other end has asked to see the full response that Salesforce is getting from their server.
Is there a way to achieve that? I have tried running with debug level 'Finest' from execute anonymous, but that yields the same little message with no further detail.
The message you are getting is because an error is generated as Saleforce is trying to parse the response is and it isn't logged unfortunately.
The parsing error is happening because instead of a SOAP message response you are getting an HTML page. This usually happens when you are accessing a service that is protected behind a firewall. Which means you may be able to see the service when browsing on your computer but remember that Salesforce is outside of your firewall and thus any communication by Salesforce to your service will be blocked.
Couple of ways to address this but this wiki topic from Salesforce best covers the options:
http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_om_outboundmessaging_security.htm
The above is specific to outbound messaging but essentially the technology issues are the same.
Don't forget that Apex includes an HttpRequest Class that works as a lower layer than the SOAP APIs. You should be able to write up a test method that sends a hard-coded XML request to the server and dumps the HttpResponse so you can see it.
Adding my own best answer, based on some internet research:
You can use an external tool like Runscope as a webservice proxy to automatically forward requests and pass through responses and view the XML SOAP messages. This is not a native solution on SFDC but it does do the job.
https://www.runscope.com/
The issue is that Force.com is trying to parse a SOAP response that's actually just HTML. This happens sometimes when an error occurred server-side and the response is meant for a browser to display, rather than sending back an exception report via a properly formatted SOAP response.
If they can't figure out why they are not sending back a consumable SOAP response, then you can try using other tools (outside of Force.com) to make the same webservice call from your browser and then see what the HTML actually says on return.
My web application uses ajax and i check request is ajax request or not via php codes. If not then i generate 404 error otherwise run php codes that associated ajax function.
If user or search spider tries to reach ajax function page(ex: /books/ajax/books_list) web app return 404 not found status code and i see a lot of 404 errors in google webmaster tools.
I should change 404 status code but which one is right for this condition ? Can be "406 not acceptable" ?
I think 403 (Forbidden) probably best describes it. The resource is there, but you've determined that you're not going to give access to that resource, and even authenticating the user isn't going to help.
I would suggest that you return the 406 you suggested. The only alternatives worth considering are '501 not implemented'
The server does not support the functionality required to fulfill the request.
This is the appropriate response when the server does not recognize the request
method and is not capable of supporting it for any resource
And '403 Forbidden'
The server understood the request, but is refusing to fulfill it.
Authorization will not help and the request SHOULD NOT be repeated.
If the request method was not HEAD and the server wishes to make
public why the request has not been fulfilled, it SHOULD describe
the reason for the refusal in the entity. If the server does not
wish to make this information available to the client, the status
code 404 (Not Found) can be used instead.
Not sure how you determine whether it's a proper Ajax request. If you expect it to be POST, but the spider uses GET, then it should be 405 (Method Not Allowed).
You should not be using 406: it means "not acceptable", in the sense that you cannot support the HTTP Accept: headers that the browser sent. This would likely be incorrect (as you likely aren't checking the Accept headers at all).
If you really reject the request because it comes from an unauthorized client, then 403 is appropriate.
It's my understanding that SE spiders get a little skittish if they see errors that indicate server problems. (A 406 can indicate a badly implemented server.) A 404 doesn't describe what you're looking for, as the resource is there, but a 403 (forbidden) just lets the spider know that this page isn't for them. You can also use your robots.txt file.