Hi,
I have some problems with HTTP API:
When i send this:
http://192.168.1.16:8888/api/services/chatBot/getResponse/%22EVE_PORTE_…
(It is for my domotic system)
I receive this:
{"msgId":1501790559340,"name":"WebGui","sender":"WebGui","sendingMethod":"","historyList":[],"method":"onStatus","data":[{"level":"error","key":"IOException - invalid api","detail":"java.io.IOException: invalid api\r\n\tat org.myrobotlab.service.WebGui.handle(WebGui.java:529)\r\n\tat org.atmosphere.nettosphere.Config$Builder$1.onRequest(Config.java:411)\r\n\tat org.atmosphere.cpr.AsynchronousProcessor.action(AsynchronousProcessor.java:206)\r\n\tat org.atmosphere.cpr.AsynchronousProcessor.suspended(AsynchronousProcessor.java:108)\r\n\tat org.atmosphere.nettosphere.BridgeRuntime$2.suspended(BridgeRuntime.java:203)\r\n\tat org.atmosphere.container.NettyCometSupport.service(NettyCometSupport.java:52)\r\n\tat org.atmosphere.cpr.AtmosphereFramework.doCometSupport(AtmosphereFramework.java:2242)\r\n\tat org.atmosphere.nettosphere.BridgeRuntime.handleHttp(BridgeRuntime.java:547)\r\n\tat org.atmosphere.nettosphere.BridgeRuntime.messageReceived(BridgeRuntime.java:271)\r\n\tat org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)\r\n\tat org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)\r\n\tat org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)\r\n\tat org.jboss.netty.handler.stream.ChunkedWriteHandler.handleUpstream(ChunkedWriteHandler.java:142)\r\n\tat org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)\r\n\tat org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)\r\n\tat org.jboss.netty.handler.codec.http.HttpChunkAggregator.messageReceived(HttpChunkAggregator.java:145)\r\n\tat org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)\r\n\tat org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)\r\n\tat org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)\r\n\tat org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296)\r\n\tat org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:459)\r\n\tat org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:536)\r\n\tat org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:435)\r\n\tat org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)\r\n\tat org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)\r\n\tat org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559)\r\n\tat org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)\r\n\tat org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)\r\n\tat org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88)\r\n\tat org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:108)\r\n\tat org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337)\r\n\tat org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:89)\r\n\tat org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)\r\n\tat org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)\r\n\tat org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)\r\n\tat java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)\r\n\tat java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)\r\n\tat java.lang.Thread.run(Thread.java:745)\r\n"}]}Before DL4J service, i receive this:
{"session":"default","msg":"","payloads":[{"serviceName":"python","methodName":"exec","params":["eveDomotic(1)"]}],"timestamp":"Aug 3, 2017 10:00:53 PM"}
and it works...
I don't know why ? Do you have an idea ?
Thank you.
HTTP Issues
Hi Dom!
I've ran into similar issues before. MRL doesn't automatically expand the escape codes as far as I can tell from the source code (unless Atmosphere handles this internally, which doesn't seem to be the case). It also hates quotes, as I found out while trying to test ProgramAB! Looking at the stacktrace, it looks like there are extra characters in the /api/ bit, which would cause it freak out because technicaly it's not the same as just /api/, even though those characters are invisble. Strangely though, the /t is a tab and should show up quite easily...
I switched over to HTTP method PUT instead of GET and formatted the arguments into a json body. Took awhile to figure out, but now I've created a very easy-to-use command-line script to do exactly what you want. It's in my mrlpy Python package, installable via pip (mrlpy), and the source code is on Github at https://github.com/AutonomicPerfection/mrlpy (also includes usage examples and extra features such as service creation and compatibility mode for running scripts meant for MRL's Python service). Requires Python 2.7 and various libraries. Installing through pip will automatically install dependencies. Supports both asynchronous (no return values) and synchronous (with return values) API modes.
Mrlpy is still under development, so it might not work for everything, but hopefully it will work for you!
The extra characters in /api/ worries me though, so I'll have to run some tests to see if something broke on MRL-side
My mistake, those characters
My mistake, those characters are part of the stacktrace ending character sequence, not part of the actual error. I would try removing the trailing s on services, but I'm pretty sure it doesn't matter (new check in webgui should have fixed that). If that doesn't work, then it's likely the escape characters. GET method has limitations in MRL http API, and escape codes was one of them, along with no quotes, special URL charactes, or spaces.
Hope this helps!
CLI works, http API is no worky
So, intresting, I was able to reproduce this error pretty easily.. using the CLI on the agent, I was able to get the response, but another interesting error cropped up when I did that which is
Thank you KWatters.
Thank you KWatters.
I think this would be pretty
I think this would be pretty easy and quick to figure out if a noWorky was submitted.
Findings
Okay, I looked into it and the WebGui has been refactored again. It looks like the alias for services API has been dropped, so just change the "services" in the URL to "service". However, that might not fix your problem. The WebGui has been refactored to send the data to an ApiFactory, which doesn't seem to be receiving the necessary data. For example: Any data in the JSON header is ignored and passed in as null. I don't know Atmosphere very well, so I couldn't really tell you why this is happening, only that it's likely related to the last refactor.
Hope this helps!
OK, it works when i change
OK, it works when i change "services" to "service" but answer is NULL, it's not a problem for me.
Thank you AutonomicPerfec..
AutonomicPerfectionist is
AutonomicPerfectionist is completely correct ..
There has been a large refactoring of the WebGui, it's a "very good thing". Previously, decoding was done differently in different services. (Cli, WebGui, Xmpp, Mqtt & RemoteAdapter). The refactoring is a first attempt to get them all to start using the same mechanism to decode & encode messages, making the MRL API more "standardized"
In the process, "services" was dropped. There currently only 2 apis which use JSON. They are "message" & "service"
services - is no longer supported.