URLs for JSON access

[Kent Multer]

Hi folks, I'm writing a module that will accept incoming JSON requests. I'd like to provide short URLs for accessing json.mvc, so that, for example, the client can use

https://TheStore.com/update/

instead of

https://TheStore.com/mm5/json.mvc?Store_Code=XXX&Session_Type=runtime&Function=Module&Module_Code=YYY&Module_Function=UPDATE

I can't use URI Management because this is an older store that's using Legacy SEO. Can someone please tell me the .htaccess code to use for this?

Thanks --

[ILoveHostasaurus]

If you want to have any hope that the functionality will remain working long term and be compatible with changes that may occur to the store and its underlying web service infrastructure, you should use the proper json.mvc endpoint for API access. Also not clear why you'd be implementing it this way vs extending the API via the json_api feature.

[Kent Multer]

The documentation on the json_api feature is sketchy at best; and I'm familiar with the older API from previous projects. I'd like to get something working quickly for testing and development, and add the security-related features later, before we go live.

Also, json_api apparently requires that Miva-specific stuff like Store_Code be included in the request body. That makes extra work for the client.

The doc doesn't tell what the "proper" endpoint is for json_api requests. Is it just the standard xxx.com/mm5/json.mvc, with no URL parameters?

The example in the doc just shows how to do the bare minimum of functionality. It doesn't show how to do a real-life task that involves passing some data to the store, e.g. to create or update a new record in some table.

And if/when we do use json_api, my question still applies. The client has specifically asked for the store to accept inbound URLs in a form like what I showed. Can we use .htaccess to transform those into something the store will accept?

Thanks --

[ILoveHostasaurus]

The documentation on the json_api feature is sketchy at best; and I'm familiar with the older API from previous projects. I'd like to get something working quickly for testing and development, and add the security-related features later, before we go live.

I would recommend against that approach. The security code is the most critical aspect and should be developed first rather than hope to figure it out later, especially given the fact that doing things properly from a security standpoint may have implications on how the functionality is implemented. The security code should be reusable.

Also, json_api apparently requires that Miva-specific stuff like Store_Code be included in the request body. That makes extra work for the client.

If moving a query string variable to a post variable is 'extra work', this client should not be developing integrations with anything. That would be perhaps 30 seconds more work than a cut and paste in the integration code.

The doc doesn't tell what the "proper" endpoint is for json_api requests. Is it just the standard xxx.com/mm5/json.mvc, with no URL parameters?

"API Endpoints" is paragraph three on the first page of the API Getting Started Guide https://docs.miva.com/json-api/

The example in the doc just shows how to do the bare minimum of functionality. It doesn't show how to do a real-life task that involves passing some data to the store, e.g. to create or update a new record in some table.

I don't know what type of data you're trying to update, but the API docs have examples for quite a bit of it. Product update for example:

https://docs.miva.com/json-api/functions/product_update

It lists all of the supported fields and then shows an example, possible errors, etc.

If you're deploying a module-based extension to the API functionality, you'd call that with the functions/variables relevant to your extension.

And if/when we do use json_api, my question still applies. The client has specifically asked for the store to accept inbound URLs in a form like what I showed. Can we use .htaccess to transform those into something the store will accept?

Thanks --

My answer still applies. We won't support or provide assistance with making use of the API via an endpoint it was not designed for.