HTTP Enhancements

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.

Binary mode would also be sweet.

well the LuaJ bug hinders that a little.

theoriginalbit, on 12 April 2015 - 11: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.

This is true

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? :D/> (Just a little idea to keep the old "api" for all old programs)



+1

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

http.enhanced( true ) - And now it should work? :D/> (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.

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 :D/>)

SeaLife, on 17 April 2015 - 09: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 :D/>)

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

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

SeaLife, on 17 April 2015 - 09: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 :D/>/>)

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

That would still break backwards compatibility.

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

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

SeaLife, on 17 April 2015 - 09: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 :D/>/>)

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".

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

flaghacker, on 18 April 2015 - 03: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.

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

Freack100, on 18 April 2015 - 04: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, on 19 April 2015 - 08:05 AM said:

http://www.computercraft.info/forums2/index.php?/topic/16881-computercraft-beta-versions-download-and-discussion-174pr20-released-april-9th/page__view__findpost__p__213124

Nice!

flaghacker, on 18 April 2015 - 03: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?

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

flaghacker, on 18 April 2015 - 03: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 :D/>


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

SeaLife, on 21 April 2015 - 04: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.

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

SeaLife, on 21 April 2015 - 04: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…

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

-snip-

HTTP API, take note of the optional header argument

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

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?

PLEASE PLEASE OH GOD PLEASE!!!

That is all I have to say.

Apparently that isn't all I have to say. Personally, I think the best choice would be to deprecate the current http api (but not remove it, to leave compatibility).

A new xhttp api would be rolled out based around a core function (which would accept any value for request_type, even illegal ones):

xhttp.request(request_type, url, [headers], [data]) -- Since headers needs to be a table and data a string, it should
                                                    -- be simple to figure out which one is omitted when one is

Now, unlike with the current http api, only outright failures (e.g. time out / cannot resolve) to respond would trigger a "xhttp_failure" event. Any actual response, even a error response such as a 404 would trigger a "xhttp_response" event. (an appropriate "http_failure" or "http_success" event would still be sent for compatibility) The handle from the event would be the same as that from an "http_success" event, except it would have an additional "handle.getHeaders()" method.

dimitriye98, on 04 June 2015 - 09:08 PM said:

Apparently that isn't all I have to say. Personally, I think the best choice would be to deprecate the current http api (but not remove it, to leave compatibility).

A new xhttp api would be rolled out based around a core function (which would accept any value for request_type, even illegal ones):

xhttp.request(request_type, url, [headers], [data]) -- Since headers needs to be a table and data a string, it should
													-- be simple to figure out which one is omitted when one is

Now, unlike with the current http api, only outright failures (e.g. time out / cannot resolve) to respond would trigger a "xhttp_failure" event. Any actual response, even a error response such as a 404 would trigger a "xhttp_response" event. (an appropriate "http_failure" or "http_success" event would still be sent for compatibility) The handle from the event would be the same as that from an "http_success" event, except it would have an additional "handle.getHeaders()" method.

Should also be able to ask for a binary mode handle, so that binary data can be properly downloaded.

ElvishJerricco, on 04 June 2015 - 10:15 PM said:

Should also be able to ask for a binary mode handle, so that binary data can be properly downloaded.

Indeed. If there's a single change this needs to be it.

I'll LOUDLY bump this, since it never got a response, and the request is valid as ever.

These features would be a gamechanger if implemented. Full http support would be absolutely insane.

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

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? :D/> (Just a little idea to keep the old "api" for all old programs)



+1

You already can read the HTTP-State:
conn = http.get("http://example.com")
resultcode = conn.getResponseCode()

Source: http://www.computercraft.info/wiki/HTTP_(API)

COOLGAMETUBE, on 17 October 2015 - 06:16 PM said:

You already can read the HTTP-State:
conn = http.get("http://example.com")
resultcode = conn.getResponseCode()

Source: http://www.computerc.../wiki/HTTP_(API)

Not if an error occurs (such as a 404 or 500). This makes it near-impossible to debug HTTP applications (particularly APIs such as GitHub's/GitLab's/Dropbox's).

Hmmmm, shouldn't be too hard to add to CCTweaks though :)/>.

SquidDev, on 17 October 2015 - 06:19 PM said:

COOLGAMETUBE, on 17 October 2015 - 06:16 PM said:

You already can read the HTTP-State:
conn = http.get("http://example.com")
resultcode = conn.getResponseCode()

Source: http://www.computerc.../wiki/HTTP_(API)

Not if an error occurs (such as a 404 or 500). This makes it near-impossible to debug HTTP applications (particularly APIs such as GitHub's/GitLab's/Dropbox's).

Hmmmm, shouldn't be too hard to add to CCTweaks though :)/>/>.

Internet antenna peripheral

Konlab, on 18 October 2015 - 03:53 PM said:

SquidDev, on 17 October 2015 - 06:19 PM said:

Hmmmm, shouldn't be too hard to add to CCTweaks though :)/>/>.

Internet antenna peripheral

Nah, I just patched the HTTP API.

SquidDev, on 18 October 2015 - 09:07 PM said:

Konlab, on 18 October 2015 - 03:53 PM said:

SquidDev, on 17 October 2015 - 06:19 PM said:

Hmmmm, shouldn't be too hard to add to CCTweaks though :)/>/>/>.

Internet antenna peripheral

Nah, I just patched the HTTP API.

That looks like an IPeripheral implementation for a peripheral block

Konlab, on 19 October 2015 - 03:29 PM said:

That looks like an IPeripheral implementation for a peripheral block

The implementation for a Lua API or a Peripheral is pretty similar.