31 replies to this topic

[theoriginalbit]

Firstly I would love to see the ability to get the http header from the response, we have the ability to set the header, why don't we have the ability to read the header too? It could open up a world of more advanced clients with the likes of GitHub and such.

Secondly I would love to see more HTTP Request Methods. I have a few RESTful APIs that I wish to use that make use of GET, POST, PUT, and DELETE; I would also like to make my own APIs which use these for some upcoming projects. The current implementation of the http api doesn't not allow anything other than GET and POST. I feel like it shouldn't be too difficult given the recent changes in CC for you to add in Java-side the http.put and http.delete in addition to the existing http.get and http.post. Having PATCH might be useful as well for some RESTful APIs, however it is a little less commonly used.

[ElvishJerricco]

Binary mode would also be sweet.

[theoriginalbit]

well the LuaJ bug hinders that a little.

[ElvishJerricco]

theoriginalbit, on 12 April 2015 - 10:03 AM, said:

well the LuaJ bug hinders that a little.

Not if gone the way of file IO's binary handling, where reading returns numbers instead of strings.

[theoriginalbit]

This is true

[SeaLife]

This would be very helpful to play with the GitLab Api

Cause it returns 401 http-codes with text which i need to use... (Like: {"message": "No Permitted"})

http.get( url ), http.post( url ) and http.return( ) should always return an Object

* Header (With the Code and so on...)
* Content (Even 404-Messages)


Or an mode?

http.enhanced( true ) - And now it should work? (Just a little idea to keep the old "api" for all old programs)



+1

[theoriginalbit]

SeaLife, on 16 April 2015 - 06:53 PM, said:

http.enhanced( true ) - And now it should work? (Just a little idea to keep the old "api" for all old programs)

well the idea that I have would still allow old programs to work as there would just be extra methods on the HTTP API, and more methods on their result.

[SeaLife]

mhh...

the problem is, now the program check with "if h then" (h = http.get(url))

but now, everytime (even if the answer is 404), "h" would contain functions... "if not h then" would never happen then (eq. to "if h then" would always be true)

if enhanced mode is off, it'll return "nil" ohn failure.. like now...

with enhanced on, it should always return something.. like h.getResponseCode() (404, 201, 401, 403, ...) (even on failure, because it is not real a failure )

[H4X0RZ]

SeaLife, on 17 April 2015 - 08:26 PM, said:

mhh...

the problem is, now the program check with "if h then" (h = http.get(url))

but now, everytime (even if the answer is 404), "h" would contain functions... "if not h then" would never happen then (eq. to "if h then" would always be true)

if enhanced mode is off, it'll return "nil" ohn failure.. like now...

with enhanced on, it should always return something.. like h.getResponseCode() (404, 201, 401, 403, ...) (even on failure, because it is not real a failure )

Then there could be a function like hasFailed() to check if an error happened.

[flaghacker]

Freack100, on 18 April 2015 - 12:16 PM, said:

SeaLife, on 17 April 2015 - 08:26 PM, said:

mhh...

the problem is, now the program check with "if h then" (h = http.get(url))

but now, everytime (even if the answer is 404), "h" would contain functions... "if not h then" would never happen then (eq. to "if h then" would always be true)

if enhanced mode is off, it'll return "nil" ohn failure.. like now...

with enhanced on, it should always return something.. like h.getResponseCode() (404, 201, 401, 403, ...) (even on failure, because it is not real a failure />)

Then there could be a function like hasFailed() to check if an error happened.

That would still break backwards compatibility.

[H4X0RZ]

flaghacker, on 18 April 2015 - 02:43 PM, said:

Freack100, on 18 April 2015 - 12:16 PM, said:

SeaLife, on 17 April 2015 - 08:26 PM, said:

mhh...

the problem is, now the program check with "if h then" (h = http.get(url))

but now, everytime (even if the answer is 404), "h" would contain functions... "if not h then" would never happen then (eq. to "if h then" would always be true)

if enhanced mode is off, it'll return "nil" ohn failure.. like now...

with enhanced on, it should always return something.. like h.getResponseCode() (404, 201, 401, 403, ...) (even on failure, because it is not real a failure />)

Then there could be a function like hasFailed() to check if an error happened.

That would still break backwards compatibility.

Yes, it would break backward compatibility. But it won't be a big problem to update a program to these new "standards".

[theoriginalbit]

Freack100, on 18 April 2015 - 03:07 PM, said:

flaghacker, on 18 April 2015 - 02:43 PM, said:

That would still break backwards compatibility.

Yes, it would break backward compatibility. But it won't be a big problem to update a program to these new "standards".

The other thing to remember, Dan is going to move over to Lua 5.2, that will break a lot of programs.

[flaghacker]

theoriginalbit, on 19 April 2015 - 12:26 AM, said:

Freack100, on 18 April 2015 - 03:07 PM, said:

The other thing to remember, Dan is going to move over to Lua 5.2, that will break a lot of programs.

Is he? I thought he didn't want to do that?

[Bomb Bloke]

http://www.computerc...post__p__213124

[flaghacker]

Bomb Bloke, on 19 April 2015 - 07:05 AM, said:

http://www.computerc...post__p__213124

Nice!

[ardera]

flaghacker, on 18 April 2015 - 02:43 PM, said:

That would still break backwards compatibility.

What about adding a xhttp API which allows you to do everything that is possible in the web, and modify the http API so it's just a simple wrapper around the xhttp API?

[SeaLife]

ardera, on 20 April 2015 - 07:41 PM, said:

flaghacker, on 18 April 2015 - 02:43 PM, said:

That would still break backwards compatibility.

What about adding a xhttp API which allows you to do everything that is possible in the web, and modify the http API so it's just a simple wrapper around the xhttp API?

seems legit...

i like the idea...

it would help me to use JIRA RestAPI and some other POST (with Json) apis...
For Jira (e.g.) you've to edit the Header to send: Content-Type: application/json

if xhttp would make this possible, i will fall in love with @dan200


(Sorry for this bad english... im from Germany :I )

[MKlegoman357]

SeaLife, on 21 April 2015 - 03:54 PM, said:

For Jira (e.g.) you've to edit the Header to send: Content-Type: application/json

You can already send request headers. What you cannot do is get response headers.

[SeaLife]

MKlegoman357, on 21 April 2015 - 05:09 PM, said:

SeaLife, on 21 April 2015 - 03:54 PM, said:

For Jira (e.g.) you've to edit the Header to send: Content-Type: application/json

You can already send request headers. What you cannot do is get response headers.

Seems legit...

[theoriginalbit]

SeaLife, on 22 April 2015 - 04:38 PM, said:

-snip-

HTTP API, take note of the optional header argument