[JohnMakin]

> About being able to use a RESTful API directly from a browser: browsers only use the GET and POST HTTP methods, among the ones REST associates meaning to. You cannot use a RESTful API from the browser, because the PUT, PATCH, and DELETE methods are not used by the browser, and even the POST method cannot be used without a UI. Also, even if you could, APIs are for machines, not humans. The user experience would be dreadful if you had to use a RESTful API directly from a browser, without a specific UI for it.

This.. isn't true?

[munk-a]

It's kinda true if you're thinking purely about submitting requests through `<form>` elements - but even then you can bend browsers to support other verbs.

[user3939382]

There are multiple RFCs with lists of HTTP verbs and axios only supports the more limited set, which for my particular legacy project meant I couldn't use any of the creative ones.

[munk-a]

That really just sounds like an axios issue - I've built in support for custom verbs with nothing but plain-old ES5 javascript. The verb is nothing more than a string component of the HTTP request and it's pretty trivial to modify it to your liking (even outside of standard verbs!).

[stronglikedan]

> without a specific UI for it

None of my browsers seem to have PUT, PATCH, and DELETE baked into the standard UI (or even POST really), so maybe it is true?

[gweinberg]

I just checked the MDN docs https://developer.mozilla.org/en-US/docs/Web/HTML/Element/fo... The only allowed form methods are get, post, and dialog. So you can't do put, patch, or delete via a form.

[Turing_Machine]

Sure you can. You just can't specify it as a form action.

There's nothing to stop you from using form elements to get your user inputs as normal, then wiring up your own "submit" button that calls your own Javascript to use any method you want. JS fetch, for example, lets you put anything you want in the method: field. I think you can even specify custom methods that only have meaning for your specific server-side code.

[quickthrower2]

They mean you can’t interact with a raw API from the browser. Unless you are just doing vanilla gets.

You might use a REST client instead or what some services do is offer a playground coded in JS to play with the end point but such a playground needs to deal with CORS.

[lolinder]

But this also isn't true—fetch can run all the HTTP request verbs.

What they seem to mean is that you can't access most of them via the GUI directly, which is true, but their "solution" is to make queries and commands both use POST, which means they've now thrown away the ability to even access read-only endpoints via the GUI.

[quickthrower2]

Ok I accept that - I guess you could F12, drop into the console and then fetch. Which is broadly similar to using curl.

I also don't like the idea of making queries and commands use POST. It kind of sucks (unless you are doing it for a website that is trying to avoid using JS for some reason).

[Turing_Machine]

> But this also isn't true—fetch can run all the HTTP request verbs.

Yep, or even custom ones that you've defined for specialized purposes (obviously you have to make sure your server also understands them).