🚀 Feature: Restful appwrite function method restriction

[mbos2]

🔖 Feature description

Restriction on which method can restful appwrite function endpoint recieve.

🎤 Pitch

Restful methods are usually used like this:

• GET to retrieve a resource;
• PUT to change the state of or update a resource
• POST to create a resource
• DELETE to remove it.

It would be nice to be able to limit which of those can a Restful appwrite function endpoint recieve, and to return internal rest error if wrong method is sent.
Specifically, HTTP 405 - Method not allowed

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/405

👀 Have you spent some time to check if this issue has been raised before?

• I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct

[eldadfux]

Why would you choose to not handle that from your function code? I get why you want to limit it, but if we start creating this kind of features directly in Appwrite wouldn't that become an endless list?

Curious to understand the use case a bit better, and your thoughts about this level of abstraction vs flexibility you have today.

[mbos2]

Why would you choose to not handle that from your function code? I get why you want to limit it, but if we start creating this kind of features directly in Appwrite wouldn't that become an endless list?

Curious to understand the use case a bit better, and your thoughts about this level of abstraction vs flexibility you have today.

I don't think it would become an endless list. :)
This one is more leaning towards Rest API best practices.

Here are some reasons for this:

• Keep our code cleaner, without having to write a lot of network checks in the function code.
• Making sure users follow proper usage pattern for the restful url
• It can be more clear what the endpoint does
• • It would also help us make sure we avoid HTTP method overloading
• • Potential of having slightly less complex code

Also, if we don't do checks for HTTP method in the code, it means (I think) slightly less execution time.

One of the best practices for cloud functions is have it do one thing, and do it good.
By ensuring only specifc method is allowed we can ensure that method happens, and we don't need to do method checks in the code, as mentioned above.

Again, it would only be optional feature for those who want to use it and make further API restrictions without additional code.

[eldadfux]

Interesting perspectives. Do you think we should focus only on the 4/5 method around REST or all HTTP methods?
I would also love to hear more feedback from the community, about this and similar HTTP checks devs would see as reasonable to add on Appwrite.

It's very important in this kind of decisions before we have a go/no-go moment to make sure we understand the full scope and have a clear framework for what should be and shouldn't be abstracted to keep the system complexity relatively low and make sure Appwrite is great for both beginners and senior developers.

[mbos2]

I forgot to mention PATCH method.
So along that one, it's 5 methods.

But yes, understandable.

I would also like to see more perspectives on this topic :)

[ItzNotABug]

Here's my take on this :

1. Code cleanliness - I don't think this a problem. A 1/2 line check wouldn't make a difference here. Simply reject the request if its not the intended one.

if (req.method !== 'GET') return res.send("Only GET is allowed here", 405);

2. Pattern for rest url - This tends to be project or organization-specific.. Its best to allow what the org. wants to do here.

3. Endpoint Clarity - This largely falls on the developer. Project documentation, platforms like GitHub can efficiently handle this.

4. Execution Time - This would be extremely negligible imho.

5. Best Practice - Consider a form like function (available in templates) which handles multiple request methods like GET & POST.
   Should we split this into separate functions?
   This may create quite many functions I guess.