How to use request body for PUT and PATCH requests?

Wappler General How To
#4

Thanks TMR. Yes I have, same result, just returns empty.

#5

Have you tried $_PUT.test? You do need to input that manually in the expression editor as it’s not in the UI

#6

There are limitations in Wappler’s Server Connect and API Actions. Currently, they only support GET and POST. I raised a feature request a while ago.

1 Like
#7

Thanks for posting that, I didn’t know about it. I’m about to start creating our own API so would have definitely stumbled over the OPs issue here, your post has saved me a heap of time working that one out.

1 Like
#8

I thought I’d give everyone an update and solution here for those that are stuck on this issue.

We ended up adding two lines to our lib/core/app.js file so that it now passes the request body into a $_PUT and $_PATCH variable.You can then use like Apple user suggested earlier, it works great! It would be nice if the guys at Wappler implement it permanently.

To Fix:

  1. Open the /lib/core/app.js file in a text editor (Sublime, Notepad++ or similar)
  2. Find line 45: “$_POST: req.method == ‘POST’ ? req.body : {},”
  3. Create a new line underneath with: $_PUT: req.method == ‘PUT’ ? req.body : {},
  4. Create a new line again, with: $_PATCH: req.method == ‘PATCH’ ? req.body : {},
  5. Save the file.

You can now add JSON into a PUT or PATCH endpoint request body, and get these values by adding the dot notation to $_PUT and $_PATCH. For example: $_PUT.name, $_PUT.test, $_PATCH.test etc.

Obviously if Wappler does an update of the app.js file code you might need to re-implement the change, but it works great for now.

image
image1198×472 64.6 KB

2 Likes
#9

@hs-rene that’s excellent! thanks for posting , its a great help.

#10

Hopefully we can get the Wappler team to make these improvements. :crossed_fingers:

1 Like
#11

I think it would be easier to just remove the POST method check and use the $_POST always for the request body instead of having different variables for different kinds of requests.

#12

Why can’t we have the standard REST methods available to use as we see fit in our apps? I want to build my apps using standard practices that don’t require sending extra params to define whether something is a delete, an update, or a new object.

1 Like
#13

That is what Patrick is saying, that you can have all the methods available and no matter of the request method you will have all the data available under the $_POST

#14

Will the server recognize the Request Method, so this SC functions correctly?

image
image601×556 11.5 KB

I know part of the issue I’ve run into is with CORS not allowing the methods.

#15

Well you are using your own case for the request method checking, so what is the problem here of not being recognized?

#16
  1. CORS, as mentioned in the above bug report
  2. Server Connects do not support any methods other than GET AND POST, so API Actions is only alternative. And the API actions still have some defects/limitations that need correcting before being able to support all REST methods.
#17

Do not use the static Url of the Api Action component, instead add the dynamic Url attribute where you can use an expression for the url.

image
image406×641 18 KB

#18

Thanks for looking at this @George and @patrick. It would be ideal to have all request method data available in $_POST. Make sense to keep it simple. Is it something that could be implemented in an upcoming release please? :pray:

1 Like
#19

I had CORS block any route other than GET and POST initially too. These defaults definitely make sense from a security perspective so no complaints or a bug that I can see. It’s an easy change in the ServerConnect settings under the CORS tab to add the other request methods and origin. Hope that helps.

#20
#21

Fixed in Wappler 6.0.2

1 Like
#22
#23

This topic was automatically closed after 3 days. New replies are no longer allowed.