If anyone has experience using the ZoneEdit API, I'd be grateful for your guidance. I've been trying to use it for a hour now and have gotten nowhere.
I started with a simple service, the getIP method in their UTIL service, doing:
curl -X POST -i -d "{'action':'getIP'} -H "Content-Type: text/json" https://newapi.zoneedit.com/Util.action
All I ever get in response though is:
{"success":false,"message":"Unknown directive: ''","map":[]}
Their docs: introduction, util methods
I'm not sure where I'm going wrong but any help would be appreciated.
I'm not familiar with the ZoneEdit api but I got the same error you did until I modified the request as follows:
curl -X POST -i -d "action=getIP" https://newapi.zoneedit.com/Util.action
That returned my IP address in plain text.
Related
I am using a Ricoh Theta Z1 updated to the most recent firmware (1.60.1). I am trying to debug an Android application, but I found that one of our commands was repeatedly failing, so I connected to the camera directly from my dev box and tested the protocol directly via curl.
It's my understanding from the documentation that this command should work:
$ curl -X POST -H "Content-Type: application/json; charset=UTF-8" -d '{"name":"camera.setOptions", "parameters":{"options":{"captureMode":"image","fileFormat":{"height":3360,"type":"jpeg","width":6720}}}}' http://192.168.1.1/osc/commands/execute
But when I run this command I get this response:
{"error":{"code":"invalidParameterValue","message":"Any input parameter or option name is recognized, but its value is invalid."},"name":"camera.setOptions","state":"error"}
This in spite of the fact that when I ask the camera about its options, it responds with the exact block it has just told me wouldn't parse:
$ curl -X POST -H "Content-Type: application/json; charset=UTF-8" -d '{"name":"camera.getOptions", "parameters":{"optionNames":["clientVersion","captureMode","fileFormat"]}}' http://192.168.1.1/osc/commands/execute
gets this response:
{"name":"camera.getOptions","results":{"options":{"captureMode":"image","clientVersion":2,"fileFormat":{"height":3360,"type":"jpeg","width":6720}}},"state":"done"}
Furthermore, when I run the first command and omit the fileFormat parameter, the command executes just fine.
Any ideas what I am doing wrong here?
After a bunch of trial and error, I discovered that it is possible to use camera.setOptions to set the file format on the camera, but only if the fileFormat block is the only member of the options block. That is to say, this command:
$ curl -X POST -H "Content-Type: application/json; charset=UTF-8" -d '{"name":"camera.setOptions", "parameters":{"options":{"fileFormat":{"height":3360,"type":"jpeg","width":6720}}}}' http://192.168.1.1/osc/commands/execute
will succeed. I think this must be a bug in the Theta Z1 camera, because as far as I can discern from the docs (https://api.ricoh/docs/theta-web-api-v2/commands/camera.set_options/ and https://developers.google.com/streetview/open-spherical-camera/reference/camera/setoptions), there shouldn't be any restriction on what JSON goes into the options block. In any case, the workaround is simple enough: issue one command to set the file format and one or more as necessary to set the other options, and then you're good to go.
FYI, there is a similar bug with dateTimeZone. see this post
https://community.theta360.guide/t/how-setup-datetime-on-theta-camera-using-web-api/6572/3?u=craig
It seems like there are a few options that need to be set as a standalone option.
If you want to set dateTimeZone, it must be the only option set. I reported this to RICOH. I am going to post your findings on the community.theta360.guide forum to make it easier to find. Thanks.
I was able to get the my_config.json file by doing the provided curl statement and update/save it, but when I PUT it given the requested curl I am receiving a 415 error, unsupported media type. According to the documentation, it's supposed to accept the .json. This is what I'm using: curl -X PUT -u "discovered":"discoverypw" -H “Content-Type: application/json” -d#my_config.json
I supposed you are trying to update a configuration.
I tried the operation as described at the following page and could not reproduce your problem. I could update my configuration.
https://www.ibm.com/watson/developercloud/discovery/api/v1/#replace_configuration
I am having trouble requesting the current status of a resumable upload. Based on the Google Documentation, the following request should return a Range header with the current range google has of my upload, but I keep getting the following response:
Failed to parse Content-Range header
Here is my curl request:
curl -H "Content-Range: bytes */1443452365" -H "Content-Length: 0" locationUrl -X PUT
I have also tried "bytes */*" and "*/*" for the Content-Range header, but no luck.
Any ideas?
First, you need to check the correct request format like the sample given below:
curl -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"id":100}' http://localhost/api/postJsonReader.do
And, discussed in other command-line tools, when sending raw HTTP data, be aware that the POST and PUT operations will require computing the value for a Content-Length header. You can use the UNIX tool wc to compute this value. Place all the content of the HTTP body into a text file such as template_entry.xml (example used above) and run wc -c template_entry.xml. It is often difficult to debug if you accidentally use an incorrect value for the Content-Length header.
Lastly, you can request the status between chunks, not just if the upload is interrupted. If the upload request is interrupted, follow the procedure outlined in resume an interrupted upload.
I have a simply Json file stored on a ftp and when I call the url http://myurl/example.json, I receive a plain/txt type file.
How can I solve the problem ?
Thanks for any help :)
Whether file is stored on server via FTP or any other method is irrelevant. What matters is that you are requesting the file over HTTP. So you need to work on your HTTP request and response headers.
One thing you may try first, is setting the headers of your request. Here's a curl example I randomly found, that shows that (application/json is the interesting part).
curl -i -u application_name:application_password --data '{"value": "my_password"}' http://localhost:8095/crowd/rest/usermanagement/1/authentication?username=my_username --header 'Content-Type: application/json' --header 'Accept: application/json'
What also matters is the response headers that the server assigns. If you have access and rights, ensure those are set, too. A good starting point: review current response headers.
I hope you can help me getting JSON REST WSO2 Data Service work.
I use v 3.0.1 and sample data service. I suspect that I do smth wrong...
I created a resource 'products' that is bound to productsSQL query.
XML REST request work perfectly, but not JSON:
curl --request GET
http://myserver.com:9763/services/samples/RDBMSSample.HTTPEndpoint/products
-H Content-Type:"application/json"
returns
> "Fault":{"faultcode":"","faultstring":"No JSON message received
> through HTTP GET or POST","detail":""}}
From the source code looks like it expects to have some request body in request url (which is strange), so the next query is
curl --request GET
http://myserver.com:9763/services/samples/RDBMSSample.HTTPEndpoint/products?q=emptyquery
-H Content-Type:"application/json"
This one hangs and on server after several minutes I get the following exception:
> Feb 24, 2013 8:08:13 PM
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor run SEVERE:
> java.lang.ThreadDeath at java.lang.Thread.stop(Thread.java:776) at
> org.wso2.carbon.tomcat.ext.valves.CarbonStuckThreadDetectionValve.handleStuckThread(CarbonStuckThreadDetectionValve.java:121)
> at
> org.wso2.carbon.tomcat.ext.valves.CarbonStuckThreadDetectionValve.backgroundProcess(CarbonStuckThreadDetectionValve.java:175)
> at
> org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1387)
> at
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1566)
> at
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1576)
> at
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1555)
> at java.lang.Thread.run(Thread.java:680)
The following query works, however:
curl --data '{"employeesbynumber":{"employeenumber":{"$":"1002"}}}'
http://myserver.com:9763/services/samples/RDBMSSample/ --header
Content-Type:"application/json" --header
SOAPAction:"urn:employeesByNumber"
So after several hours debugging WSO2 DSS and Axis2 code there is a fix:
Reason: WSO2 still runs on Axis 1.6.1 which had some critical bugs in JSONOMBuilder and JSONDataSource (which seem to have been fixed in 1.6.2). Specifically it required all GET requests to have input parameter and also wrapped in a root element + some other issues. The fact is that inside, AXIS2 maps JSON payload to SOAP body, so needs to have root element..
Solution More of a workaround: For GET requests pass request body with parameters wrapped in a root element (and of course url encoded). Even if you do not have parameters - pass them anyway.
So the following queries work:
curl --request GET http://192.168.1.10:9763/services/samples/RDBMSSample.HTTPEndpoint/employees?q=%7B%22request%22%3A%7B%22employeeNumber%22%3A%221%22%7D%7D%20 -H Content-Type:"application/json"
And this one for query without parameter but passing dummy one anyway:
curl --request GET http://192.168.1.10:9763/ervices/samples/RDBMSSample.HTTPEndpoint/products?q=%7B%22request%22%3A%7B%22employeeNumber%22%3A%221%22%7D%7D%20 -H Content-Type:"application/json"
Hope WSO2 guys will update to latest Axis2 soon...
I think the way you call REST cal from curl is wrong if you want to play with curl you can use the reference [1].
the correct message would be
curl -i -H "Accept: application/json" http://myserver.com:9763/services/samples/RDBMSSample.HTTPEndpoint/products
Else there is a good Google chrome plugin "Advanced REST client" you can simply use it for invoke REST services.
[1]. http://blogs.plexibus.com/2009/01/15/rest-esting-with-curl/