Hi I have created a package for my metro application.Here while developing my app I have given a Url static,But I need to change Url dynamically whenever my requirement changes.So that what should I do?Can anyone help me.
Thank you.
If your requirements are changing, then you might be releasing a new version of your application anyways, so it might make sense to just update your app package manually each time the URL changes and re-release it. This is definitely the simplest solution if your URL is going to change infrequently. You would also need to handle deprecating the old URL in this instance or at least gracefully handling when the old URL is shut down so that users who have not upgraded to your latest version still don't have a horrid experience.
If that is not a viable option, then it gets a bit messier from here on. Really the only way to change the stored URL would be to have some sort of secondary service or authority on what the current URL is. The app would then do one of the following (or a combination):
Query the URL authority for the current URL before making any requests.
Attempt to make the request to the current stored URL, if it fails, query the URL authority for the new URL and store that URL.
Related
I am not able to run any other controller in the default React app for .NET Core 6.0. Has anyone figured this out? I believe I saw a quick message on the terminal about the weatherforecast route being in the SPA proxy.
Whenever I try to go to any other route for a controller it redirects to the fallback page. I have routing setup with default settings. Just seems an odd behavior.
It's obviously a proxy issue because if I run the controller from the IIS port 7132 instead of the 44402 (spa server), I am able to retrieve the json response. There's quite a long readme file in here I can plod through but maybe someone has a better solution.
Update: I found the solution, well there were several, from setting CORS policies on the server side, etc. The easiest way was to do it "pre-flight". I found a handy file called setupProxy.js (who knew lol), where I was able to set an array of end points to proxy. And this had the /weatherforecast endpoint already specified. So now it all works! I guess I answered my own question.
const context = [
"/weatherforecast","/account"
];
I'm a new to RESTful API's and sort of developing my first one at the moment for a mobile application to be followed. I have a question regarding API versions and how to manage/tackle them.
At this moment, my API 'version' is a directory named v<version_name> in which my API class resides. In that directory, I have resources that the API and REST client needs in another directory named include. So the structure is as follows: example.com/api/v0.2/method_name/ and on .htaccess, I'm making sure that everything that follows the API version (hardcoded in the .htaccess file, is saved in a query string parameter).
I'm not sure if it is the right approach for a live application as it requires manually changing the URL endpoints at clients' ends, too. So my questions are:
Is this the right approach to API versioning?
If it is and I keep it, how do I deal with outdated URL's. Say for instance the app is live and I update the API to v0.3 but the client who have the app installed would be accessing v0.2 and getting a 404 response code back?
Is there more elegant solution out there? It must be.
Edit: there are some resources that reside outside of the api folder itself, in the root include folder so to speak.
Edit 2: My API is targeted to be consumed by mobile applications and is not publicly consumable.
While I think these questions are primarily opinion-based, I will have a go...
I think it is a valid approach, and I've seen others use it,
including Microsoft.
When it is necessary to outdate an API, you could give a 404
back with an explanation that the new API is at the new address.
HOWEVER it is usually a bad idea to just retire an API version; you
would at least have to give client developers enough time to switch
to the new API before retiring the old, if at all.
A more elegant solution would be to just keep the API at one
address, and update that as necessary, and add to it rather than
replace whenever possible. Keep supporting outdated functions for as
long as possible and have open communication to client developers
about when a certain method will no longer work.
Just my opinion, do with it what you will...
I had Magento SOAP API working perfectly until the client said Doh! We need it on this url instead, after I moved it it to that new url API will not run no matter what, I've made all the necessary url changes in the API script, Configuration, the DB and the site files.
Is there somewhere the old url may be encoded where I'm not finding it using a find and replace?
For instance, I created a full cPanel back up of the site, restored it to another server, whet back through and changed all the instances of the new url back to the old url in the db, site files and configuration and WHALA! SOAP starts working again..
Thanks!
I have an app that uses a session to store an ID for the user, standard practice for most login systems. The app has worked in IE before. I'm using Heroku to host.
I recently updated the rails version to 3.0.20 because of the security concerns, and it seems that IE will not allow any cookie to be set. Cookies are stored just fine in Firefox/Chrome/Safari, but IE will not store them.
There are no underscores in the subdomain, so that's not an issue.
As far as I know the only recent change was updating the rails version to 3.0.20, which leads me to suspect there's something amiss there. Since rails 3.0.20 was created to address a security concern, I'm curious if the security changes made IE think the app is a security violation and will no longer accept cookies from it? However, I even tested IE where I told it to accept all cookies from every site, so I'm not sure what's going on here.
Anyone seen this issue recently or aware of what may be going on?
There's no stack trace or errors to show; cookies just aren't being set, which results in a standard "record not found" error.
So I finally got a link in my facebook post using the properties parameters. I thought I could put my url scheme in there. But unfortunately it says it isn't a valid url, which makes sense. So I searched again for another solution. But everyone seems to be talking about fb:// and not their own app url scheme.
So I created this thread, hope somebody can help me.
Try using bit.ly (or some other URL shortener).
The last time I tried, bit.ly accepted any URI schema and just did a redirect. I've successfully used this in the past to work around inputs that expected either an HTTP or HTTPS schema.
Additionally, similar logic could be done on your own server if you prefer. Simply share a link to your own server on Facebook, and have your server side script do a 301 to whatever App specific URI you have.