hashbang #! url patterns for REST on the client side - javascript

I've a single page application with my own custom router.
window.onhashchange = function(event) {...
and I've hash bangs like following.
#!/products
#!/products/1
#!/brands
#!/brands/1
But they seem to emphasize GET requests, I'm listening to URL changes and is there a REST based convention clean URL's based on industry standard, perhaps used by angular, React etc. to indicate a POST request or DELETE request.
So router can dispatch a respective call accordingly.

hashbang urls are not meant to indicate any REST based remote calls, instead it's used to define to state of a SPA page it's currently in. State means the kind of content that's visible for the specific hash bang url.
for instance for #!/products display product related forms, controls and associated content and vice versa for #!/brands.
It's the user actions on the associated content that the developer needs to interpret and translate them into REST specific calls.

Related

Avoid duplicate REST calls due to URL Navigation

My application is based on AngularJS 1.8 and angular-ui-router. On Successful login of the user, application is navigating user to a particular URL location by doing:
$window.location.href = "../"; //Let's call it Navigation-1
Now based on user type, the application adds query parameters to the URL, and causes another URL navigation
/?user=admin //Let's call it Navigation-2
These Navigations causes the states to retrigger (twice in this case), thus sending duplicate REST calls to the server.
My question is How do I avoid duplicate REST calls? I tried to capture events such as 'load' etc. but it doesn't work.

Will Product listing having filter, sort & search using Ajax breach REST principles?

I am building a library for listing products in a web application. It has to have filter, search and sort features. I have a web service that when called with filter, search and sort parameters can return the result set with all the those parameters applied. If page number is passed along with that, with number of products per page, it can return that specific page as well. It looks very much suitable to have the data populated through AJAX at client side using this web service. However the page will lose all the parameters (filter, search & sort) when clicking back button and coming back and the page will display the default list of products, as the URL will remain the same as below, irrespective of the filter or page or search or sort parameter
<domain>/productlist
. To retain them, I have to save these in sessionStorage or any other such mechanism. Will this be a violation of REST principles? Do I have to avoid AJAX and have the parameters always passed in the URL for the actions to be repeatable and abide by REST principles like
<domain>/productlist?filter=f1f2f3&search=apple&sort=price&order=1&page=3&items=10?
I may be wrong in understanding REST as well, as I am a bit new to this. So would like to understand better to have a proper & compliant design.
To retain them, there should have some better approaches instead of putting those params into session storage; one of the approach would be for every AJAX requests, pushing the search params into the window.history via window.history.pushState function, once user go back to previous page, all you have to do is check whether urlParams is filled with something or empty, and fetch the data according to the urlParams.
REST is a concept that how you should handle the requests throughout the frontend and backend.
AJAX is a method of fetching data from backend.
They could coexist therefore you could use AJAX and at the same time abide the statelessness of REST.

Using html5 history in place of hash urls to restore the history of the user

We have a single page application that loads results based on query string.
The query string looks like:
?city=Delhi&pn=1
The SPA has different sections on the same webpage. When user navigates to those sections, we maintain history using hash changes. For example:
?city=Delhi&pn=1#sort : Show sort parameter section of the SPA.
?city=Delhi&pn=1#filters : Show filter section of the SPA.
We are now planning to drop maintaining history using hash changes in the url and instead start using html5 history api.
How can these hash be replaces and same functionality performed using history plugin?
I tried with a + sign, for example (?city=Delhi&pn=1+sort). But looks like user cannot bookmark this and page would break since api doesn't handle + sign. + sign is taken as space in ajax api request.
What are other possibilities to handle it elegantly?
The standard means to encode the data on a query string is to add another key=value pair.
?city=Delhi&pn=1&sort=true
Note that if you are using the history API then you should have server side code capable of generating the same view that the JavaScript would generate.
e.g.
User arrives on / and gets the homepage delivered by the server
User follows a link to /?city=Delhi&pn=1&sort=true and Ajax transforms the page into another page.
User bookmarks link
User goes away
User comes back another day to their bookmark and the server (not JavaScript) builds /?city=Delhi&pn=1&sort=true
User follows another link and JS kicks in
This means that:
The site performs faster on initial load. You don't have to load the homepage and then wait for JS to make additional requests to transform it into the page you initially asked for.
It is good food for search engines
It continues to work when JS fails.

Extract React Router state in URL

I'm using react-router and redux-simple-router in conjunction with server side rendering and when I navigate to a url like:
routeActions.push({ pathname: '/main', state: 'some_state'});
I want to be able to extract some_state from the request so I can render an initial redux state and send that back to the client. How do I extract the state from the request on the server side? Where does history and react-router put it?
This is particularly important for mobile because desktop, as I've tested, doesn't fire separate requests but mobile devices do which means the page reloads with a fresh initial state.
state corresponds to state in the History API - it's associated with the current location, but it's only available on the client, so it's not suitable for passing along arbitrary data if your app needs to support server-side rendering.
If you want it to be available on the server, you would need to make it part of the URL. perhaps as a query string.
Aside: location state is useful in other ways in isomorphic/universal apps, such as passing around POSTed form data to be handled using an onEnter hook, or for passing form data and validation errors to use a redirect transition to respond by rendering an invalid form in the same scenario.

Embed param with index page

I need to embed a parameter with all my pages url. Like:
index page = www.abc.com?param=value
about us page = www.abc.com/about-us.html?param=value
When i google it I found param tag. But it is child tag of Object Tag. So I don't know how to use this to address my issue.
Note: Am adding parameter to maintain my version upgrades so that browser will fetch from server whenever new updates added not fetching from cache like Google.
How to achieve that?
When i google it I found param tag. But it is child tag of Object Tag. So I don't know how to use this to address my issue.
You can't. It has nothing to do with your issue. Object parameters and query string parameters are entirely unrelated.
Am adding parameter to maintain my version upgrades so that browser will fetch from server whenever new updates added not fetching from cache like Google.
That is used when linking to resources that change infrequently and you normally want to be heavily cached, but which occasionally change in a way that would break parts of a site if not refreshed in the browser. Primarily this applies to stylesheets and JavaScript files.
For regular pages, you usually don't want such strict caching rules so you should configure your HTTP server to put appropriate cache control headers in the HTTP response for the HTML document.
For instance:
Cache-Control:max-age=3600
ETag:"44ab-51ae9454a67e2"
mnot has a good guide if you want a more in depth explanation about how to control caching.

Categories