emoncms / emoncms

Web-app for processing, logging and visualising energy, temperature and other environmental data
https://emoncms.org
GNU Affero General Public License v3.0
1.22k stars 512 forks source link

post input from jquery ajax posting data but return error #618

Open Future-Home opened 7 years ago

Future-Home commented 7 years ago

I am having trouble posting data to my emoncms installation on a shared apache server.

Using jquery AJAX Get returns success and the requested data, however doing the same when using POST an error is returned.

http://mysite/input/post.json?node=100&apikey=myapikey&json={power:56,load:94}

If I run it through a browser it returns "ok"

Any ideas?

TrystanLea commented 7 years ago

@Future-Home did you solve this issue?

davidski commented 7 years ago

While working on an emonCMS interface, I'm also hitting a problem that seems related to @Future-Home's report. emonCMS current returns a bare ok string without the quotes. A bare string (sans quotes) is not a valid RFC 7159 JSON object (reference https://jsonformatter.curiousconcept.com for validation) which causes decoding to fail. A bare string of "ok" (with quotes) is valid and will decode correctly.

Steps to Reproduce

  1. From Firefox 54 (Windows 10 64 bit), directly visit: https://emoncms.org/input/post?apikey=YOURAPIKEY&data={"emontest":42}, replacing YOURKEY with a valid write API key.

Response

Expected Behavior

Additional Notes

pb66 commented 7 years ago

Fixing this might break backwards compatibility, it's been returning ok for ever and some softwares simply test the response is exactly equal to ok, changing it to "ok" might fail those checks, for example original emonhub will only delete data after emoncms has confirmed receipt with an ok a change to "ok" might result in the same data being presented again and again, and not moving on to subsequent data.

I'm not saying it shouldn't get fixed if that's what's needed, just that it should not be changed without fully considering and catering for any implications that may arise.

I seem to recall there was a "real json" verses "legacy mode" type setting/parameter suggested/utilized for something similar, when I remember what that was I'll post again.

davidski commented 7 years ago

Understood. This would be a good time to think about having a versioning system for the API. Going through the presented API has shown a number of inconsistencies in the current implemented code. I've been pondering putting together a bigger list of these opportunities to move to a more strictly RESTful interface.

As is, the current API is pretty awkward to work with. Doable, but items like this return issue make working with modern client libraries a bit frustrating. 😄

TrystanLea commented 4 years ago

Noting as feature request to be kept open as a reference for future development, when time/resources allow.