Add additional HTTP Methods (PUT,PATCH,DELETE etc)

[HarmonicaAlex95]

Is your feature request related to a problem? Please describe.

I'm trying to create entry for user registration integrating with online database Firebase. However with POST method, it will auto generate random unique ID keys for data storage.

There are only HTTP POST and HTTP GET which is not enough for current technology.

Lack of RESTful API which caused alot of trouble designing the desired backend data manipulation. For example, PATCH is used to edit a specific ID with a specific value while PUT is used to update/create an entry on the specified ID/key.

Source: Firebase

Describe the solution you'd like

Introducing RESTful API which adding more functions like PUT, PATCH, DELETE, OPTION and HEADER.

Describe alternatives you've considered

none because this is essentials for web developer to manipulate data parsing especially for parsing to external online database

Additional Context

https://firebase.google.com/docs/database/rest/save-data
https://firebase.google.com/docs/database/rest/retrieve-data

Sample of REST API on Postman

https://restfulapi.net/
https://www.geeksforgeeks.org/rest-api-introduction/

[shadowpanther]

As an alternative, you can create a middleware service that accepts just PUT and GET requests that Resonite can do and converts them to appropriate requests to your database.

[ProbablePrime]

I've changed the title here to make it clear you're after http methods. There are other items this could be confused with.

Thank you!

[shadowpanther]

I think that to fully work with REST, we'd need to also have full access to HTTP headers, both request and response (but that touches on Collections, I suspect).

Edit: there's:

• GET/POST String Network Headers #76 on headers
• Resonite does not send user-agent header on image requests; breaks OpenStreetMap #189 on explicitly asset getting request headers, not HTTP flux nodes, but still kinda related
• Resonite ignores caching headers #202 on processing the standard response headers for assets

[ProbablePrime]

I understand, We'll cover methods here and headers elsewhere.

[HarmonicaAlex95]

I've changed the title here to make it clear you're after http methods. There are other items this could be confused with.

Thank you!

Thank you for reclarify the title.

[Merith-TK]

on the subject of headers, supporting the basic-auth protocol would be helpful! I recently developed an simple data storage server (api/<object>/<table>/<key> style data storage) and implemented basic auth support into it (different credentials changes the target data store) but I cant utilize that just yet in the websocket connections due to wss://user:pass@sds.merith.xyz/api/example/example/ws being an invalid websocket URI unless the user-info is parsed into the headers

[Amunak]

Ideally we'd have just general ("low level") access to HTTP requests/responses for use cases that are not so "standard". The HTTP protocol (1.x) is simple enough that as long as the engine does the actual request (and potentially TLS handshake) for us you could compile and parse arbitrary HTTP requests on your own by just sending a string to the server and parsing the string you receive. That would even now allow to send any request, anywhere.

I also find it kinda odd that there are different nodes for GET and POST, when there is effectively no difference between any of the methods from the protocol's side. Hell, both can even have a body, even if it might not be advised for GET.

[Merith-TK]

To build onto amunak's response,

It would probably be possible to have an HTTP_REQUEST flux node that takes an input to determine what kind of request to make, like the chirality nodes and such

[Amunak]

It would probably be possible to have an HTTP_REQUEST flux node that takes an input to determine what kind of request to make, like the chirality nodes and such

Arguably it should just be a string input. Albeit not common, nothing prevents you from having custom HTTP verbs (methods).

[HarmonicaAlex95]

@Merith-TK I did think about having HTTP_REQUEST node with "wildcard" like how Write node behave, since there are tons of data type can pass through HTTP protocol like image, audio, video, scripts etc.
However it would be better to have each node with its individual functionality (GET, PUT, PATCH etc.) so it doesn't confuses when going down the ProtoFlux development

Source: Wikipedia on HTTP Request Methods

And up to today, I just realised it is limited to only string type. So it's potential is endless if this got developed even further