I don't see how this could be useful?

If you can set up a menu item to access com_ajax, it means you can access it by it's alias. So instead of /index.php?option=com_ajax, maybe you only need to access /ajax (or whatever you choose as the menu item alias).

Then, since the menu item can have settings of it's own, you can set some defaults. So, instead of /index.php?option=com_ajax&format=json, you only need /ajax.

You can even set a default module or plugin so that instead of /index.php?option=com_ajax&format=json&plugin=myPlugin, you would only need /ajax.

But no extensions developer can ever really use that because you can't guarentee the menu item has been created. I don't see this as been worth it tbh

What do extension developers have to do with anything? By using com_ajax, you can give your site a rudimentary API. By using this addition, you can do it with nicer looking urls.

The purpose of com_ajax itself is to give your site a rudimentary API. In my opinion, obscuring that API behind "nicer looking urls" will just make it harder to debug and encourages the construction of fragile clients (your client code will depend on the menu item being set correctly).

com_ajax is only meant to be used by modules and plugins. The call to this URL is done invisible to the user within the JavaScript code.
SEF URLs are quite meaningless there.

There's nothing that I'd love to see more than being able to achieve something like this, but I agree with @chrisdavenport @wilsonge about the risks of this. Unfortunately the video isn't available, but there was a great talk at J and Beyond about APIs and Joomla (http://jandbeyond.org/program/sessions/dont-worry-be-api-best-practices-and-implementatio.html). Essentially, the weak link in Joomla is the router and being able to achieve SEF URLs. Making them menu dependent is too great of a risk in my opinion.

To be clear, this does not stop the longhand version of urls from working. It just provides an alternative.

To be clear, this does not stop the longhand version of urls from working. It just provides an alternative.

That's obvious. I just don't see the point in creating a SEF URL for an API. It would only confuse users to have one more menu item choice. Nobody would have it as a real visible menu item anyway, there is no point for that. So we're left with a hidden menu item which is purely for creating nice URLs. But again this URLs aren't visible to the user, they're only used internally within an AJAX call.

Extensions using com_ajax don't use JRouter to create SEF URLs. There is no point wasting ressources doing that. To work properly, the extension would also need an added parameter where you can specify the Itemid you want to use, otherwise the whole thing is useless again.

So unless you can tell us what you want to solve, I'm not a fan of this.

Of course you can always do it for your own site if you think you need this for your special use. But I don't see how that would be useful for a bigger user base. It's likely only you who would use it.

I didn't really have in mind that this would be used by the host site itself. I imagined that someone might use this to simple ways for other sites, apps, whatever, to access some kind of data. Sorry it sounds pretty vague. It doesn't solve any specific issue, it's more of a "let's see what people do with this" kind of thing.

I can understand that you want to use a cleaner url but I think the new menu item screen has already a lot of options and add another one that is not being used by most users is not a good idea.

I am changing this to Needs Review so a decision can be made. It looks to me from the comments that several PLT members are saying no to it. @bakual @betweenbrain @phproberto @chrisdavenport

Closing this as there are strong comments against this from PLT members and George and nobody supporting it.

I'm hate when contributions are discarded because you invested time on this.

Thanks @okonomiyaki3000 !!!