We have a web application that currently uses URLRewrite.net, and I'm thinking about pulling it out to use Helicon's ISAPI rewrite 3.0..
We have about 100 redirect rules of varying complexity and both redirect solutions can do the job, but I'm looking to free up managed code resources for our site. I'm thinking of these links in particular: Tess's blog and Kurt's blog.
Does any one have any experience with either product? What did you think?
Related
We have two servers running with Fastly as the CDN and filtering which types of content get served by which build. In the Fastly code base, we have a .tl file and a .vcl file that contains all logic that defines which routes point to which server.
As for the code base for both servers, are all developed in Laravel.
Problem:
Is there a way to build a rule or logic of some kind that fastly forces error status to a specific server? If so, what would it look like?
By the way: my knowledge on Fastly is very limited, but I have advanced knowledge in JavaScript, PHP, regex.
I've put together a working example, using Fastly's Fiddle tool, based on my understanding of what you were trying to achieve:
https://fiddle.fastly.dev/fiddle/dd727e98
Here are some other resources available that might assist you:
VCL Examples (here's one that redirects URLs at the edge).
VCL Reference
If you have any further questions then I'd recommend reaching out to support#fastly.com who will be happy to help.
All the best.
I have an angular application running behind cloudflare and ambassador gateway routing deployed with kubernetes. What I want to do is to check from which browser the application is receiving the traffic and match it against the list of supported browsers I have. If the browser does not match, I would like to throw a static html page which says, sorry we don't support this browser and please follow the steps to upgrade your browser, etc.
Now, there are many solutions to achieve this exact same thing but, I have a hard requirement to block my website completely for unsupported browsers.
I can easily do it within my application but, why should the whole angular application be loaded just to deny access to my website. It would be really great to block the users from the root itself. Problem is that I don't have nginx, haproxy, etc in which case it would have been fairly simple and straightforward to implement this. Instead, I have cloudflare and ambassador of which I have least experience in.
Could someone please guide me on how can I achieve browser detection and redirection based on some conditions with cloudflare or ambassador?
Not sure if this is what you want, but you can configure Cloudflare to block/challenge specific user-agents using User-Agent Rules.
Additionally, Firewall Rules can also be created to match incoming requests with specific user agents to be blocked/challenged/allowed and you can combine it with other expressions.
Why do API's use different URLs? Is there two different interfaces on the web server? One processing API requests and the other web HTTP requests? For example there might be a site called www.joecoffee.com but then they use the URL www.api.joecoffe.com for their API requests. Why are different URLS being used here?
We separate ours for a couple of reasons, and they won't always apply.
Separation of concerns.
We write API code in one project, and deploy it in one unit. When we work on the API we only worry about that and we don't worry about page layout. When we do web work, that's completely separate
Different authentication mechanisms.
The way you tell a user to log in is quite different to how you tell an API client it's not authenticated.
Different scalability requirements
It might be that the API does a lot of complex operations, while the web-server serves more or less static content. So you might want to add hundreds of API servers around the world, but only have 10 web servers.
Different Clients
You might have an API for the web client and a separate API for a mobile client. Or perhaps a public one and a private / authenticated one. This might not apply to your example.
Different Technologies
Kind of an extension of Separation of concerns, but it allows you to have Linux server for one and use something like an AWS Lambda for the other.
SSL Wrangling
This one is more of an anti-reason (particularly for the specific example you give). Many sites use SSL for both web and api. Most sites are going to use SSL for the API at least. You tend to have SSL certificates matched to your URL, so there might be a reason there. That said, if you had a *.joecoffee.com certificate you would use api.joecoffee.com not www.api.joecoffee.com (because apparently an extra '.' in your URL costs more, or something like that).
As #james suggested - there's no really right answer and some debate.
What are some web apps that allow me to play with any REST APIs visually (by clicking) and also get some code generated (in any language) that captures what I have described visually?
Similar to Swagger or Google API Playground but allows me to talk to anything that speaks REST (assuming I have the proper auth credentials and I know what messages it understands).
Bonus points for something that can also "discover" what messages are understood, given a URL endpoint.
Microsoft has 2 that I know of
OData API explorer
The data market service explorer (requires signing in, and then you can access free data sets)
Considering that REST API's are going to follow their own conventions, terms, and have their own documentation (hopefully), this is an impossible problem. If you restrict your quest to visualizing API's that follow a "standard" form of self-documentation (see REST web service WSDL? for some hopeful scenarios) you might be able to accomplish this.
Or you can use something like http://www.programmableweb.com/ to discover tutorials, tools, examples, and mashups of various existing APIs.
You could mock an API at http://apiary.io/.
You could explore and existing one through tools (e.g. REST Console for Chrome)
What you can't have, is one-size-fits-all explorer for "every possible REST API." Some APIs follow conventions that others don't.
apigee and apihub (now part of mulesoft) are two that I frequently visit. Of the two, apigee is my preferred provider.
One of the reasons that you're not going to see a lot of websites like this is because of the same-origin policy. This means that you can't access a RESTful API located at api.google.com from a web app running at, say, www.restfiddle.com without sending all the API traffic through restfiddle.com's servers. Sites like JSFiddle can exist (and are used widely) because all the processing is done on the client side.
Browser plugins, however, are exempt from the same-origin policy. If you're using Chrome, try Postman. If your REST client doesn't need to be web-based, check out SoapUI. IntelliJ IDEA has a nice REST client as well.
Try Restlet Studio, it's the only visual API designer I've found, and seems pretty good, it imports and exports swagger & RAML.
http://studio.restlet.com/
I'm working with NodeJS + Mongoose, writing a Single Page Application, so I need to serve some statics and then all the interaction between frontend and backend is done via XHR. Eventually I'm thinking about writing a native mobile app accessing the same backend. Is there any pattern / best practice I should apply here?, I thought that I may need to extract the API to be exposed via Restify, and handle the requests from the webapp only with ExpressJS? or should I just put all the stuff exposed via Restify? I guess my confusion comes from not being worked with Restify before, so any explanation about how is it different from ExpressJS (specially when talking about a Single Page App) is really welcome.
I am implementing a similar solution, mobile app & website with expressjs and backbonejs. I did not use restify because i did not think i needed the extra complexity, there were not that many API endpoints so expressjs handled everything ok for me.
BTW take a look at this post on restify performance, I just saw it today and have not personally validate the contents.
Benchmarking APIs using PerfectAPI vs Express.js vs Restify.js « « PerfectAPI Blog PerfectAPI Blog http://bit.ly/xrTguB
Restify is packaging DTrace and various handlers that Express doesn't. If you just have one API endpoint and don't need DTrace, it doesn't make sense to run Restify.
Also, you might want to try express-resource