I have a general question about what Akamai can provide for web services. We are looking to develop a web service and our web service application is hosted in the US, but we would expect that our web service can be accessed from across the globe. I would like to know if 1) Akamai caches dynamic content like web services, and 2) can Akamai provide some better performance if it can cache a web service.
Such as a .ASMX endpoint where there is nothing static about it. The content is 100% dynamic as it fetches data from the back-end like a database and returns it. I’m wondering if Akamai would apply here.
Akamai can definitely be used for web services, it all comes down to your own decisions about how long content should be valid before the server (your service) needs to supply a new version of the content. In simple terms Akamai are only doing what http will do for you anyway, if you set cache control headers for the resources you serve from your API then clients will look at those headers and not request new copies of resources if you've told them that the resource is valid for 10s/10m/10h, etc.
Of course in practice Akamai does a lot more than that, firstly they have over 200k servers globally so your content will sit close to your users wherever they are in the world meaning if that content is still fresh your users will get it very quickly (from a server near them, not from your servers). Secondly, if they do need to request content from you, they do it over a super-optimised network which monitors itself to ensure the quickest route across the globe is taken. If you're concerned about them serving stale content you can even have every request go to your service to check if there's a more up to date copy, eg by using eTags.
The whole thing is highly configurable as well as being extensible from your end using custom headers to instruct their network how you want to deal with different content and endpoints. This is just a quick overview, they can do a lot more as well, definitely worth a look.
Related
I'm developing a SPA with html5 routes.
Ex: https://app.example.com/restaurants/<restaurantId>/menu etc
Basically the app creates dynamic websites for multiple restaurants, hosted at https://app.example.com/restaurants/<restaurantId>
The requirement is to allow the restaurant owners to host the site in their own domain name.
Ex: if the restaurantId of Example Pizza Shop is xxx
then www.examplepizza.com should serve the contents of https://app.example.com/restaurants/xxx along with all the sub-routes.
The project is hosted on firebase, I'm looking for ideas on how to achieve this (even if I have to use services outside firebase it's okay)
Thanks in advance.
Firebase Hosting is not well-suited to these kinds of multi-tenant use cases, and you'll find the same is true for most "platform-as-a-service" style hosting providers.
To host arbitrary custom domains, you'll need:
Dedicated IP addresses that customers can point their DNS providers to (A records).
A web server capable of dynamically changing what it serves based on the Host header of the incoming request.
An automated SSL certificate provisioning system to create certificates for each customer's custom domain.
This is generally a major undertaking and requires quite a bit of both general and specialized knowledge. I don't think Stack Overflow is going to be the right place to find a specific solution, but I hope this guides you on your journey.
I am not sure if I am comparing onion with a cabbage. But I am really confused with the portlet and a web service. I know that web service is making your software components in your application as a service to other applications but to me it is similar to a portlet responding to requests. I know that my understanding is making you(Portlet & SAAS developers) really upset. But I need some clarity on this.
Why cannot I use the request-response to portlet work similar to a web service?
If yes, what is the benefit I get in using a web service than a portlet?
If not, then what are portlets lacking to act as a web service?
I am a newbie in portlet development. Please dont curse me for this question.
Please suggest.
EDIT:
Most of the answer say that the portlet is a UI component. My customer has requested me to create a webservice in liferay. So is it to make a portlet as a web service? If yes, can you please provide a pointer or some code snippet?
Addressing your 'edit' specifically with regards to Liferay...
Liferay plugin projects can expose web services without too much work.
The Liferay Service Builder actually has facilities so you can create SOAP web services or JSON web services backed by tables in the Liferay database (and that make queries on existing database tables). In the case of JSON web services, the URL scheme generated is not RESTful (unfortunately), but it is well defined. With a bit of work on your part you can impose Liferay's permission system on web service calls as well.
Here's a reasonable starting point in the Liferay Developer's Guide:
See the links on that page to SOAP and JSON services.
Note that a 'portlet' is only one type of Liferay plugin. The web service facility is part of the service layer - which can be used by many plugin types. So there isn't necessarily a portlet involved in creating a web service in Liferay, you can make a web service that has no visual component associated with it.
Portlets are areas you create to add and display content. Portlets can be added to the left and right of the center body area and can contain myriad content ranging from news, events, calendars, RSS feeds, collections, plain text, and more. Also, you can set properties and policies for showing the portlets.
you want to use portlet when
You have content you want to have special focus, like news.
You need to specify the configuration data for an item. - i.e. number of entries to show.
You want to give the content editors a choice about when and where to display content.
You'd like to show it only to some groups or users.
On the other hand, web services:
Enables applications to expose their services
“progammatically”, i.e. the services can be invoked by programs
Enables software running on other computers (could be a desktop, mobile phone, PDA, etc.) to invoke operations exposed by Web applications
if you are trying to identify the main difference portal historically, the portlets have three layers architechture (client, middle tier, backend) this cause two weakness:
Different portal groups have no well established way of sharing services
Different technologies(Java, Perl, CORBA, EJB) in middle tier.
Different protocols(GRAM, IIOP,...)
Consequently, lots of redundancy, reinvention
Example: batch script generation
so Web services address the service sharing problem and reduces the redundancy.
source1 source2 source3
Portlets are meant to be a user interface component in a portal solution.
Web Services provide functionality to remotely interact with a system commonly using SOAP, REST, JMS or other related
They provide completely separate functions. The closest you get is the serveResource method in portlets. This functionality is used to serve various types of content from a portlet (such as a PDF document or an AJAX response) without the need to perform a full page request.
With very little experience designing mobile or web based systems, I really have no idea idea what sort of methods are generally used for exchanging information from an application on a phone with a web service on a server. In my scenario, the app is on Blackberry 10, and I think the web service will be run on Heroku.
I want to periodically exchange small amount of information between client apps and the server's web service. I have tried searching for how this might be done, but I have had no success in finding anything helpful. Any sort of information on how I can or should do this would be appreciated.
To clarify a little: I am particularly interested in how small amount of data are typically stored for transfer, and then what mechanisms are generally used for actually sending and receiving the information.
Typically, this is handled via HTTP calls through the mobile device's SDK. I have no idea what the objects are on blackberry, but the typical workflow looks like this:
Write a web service that does something (e.g. calculation, retrieve data, store data).
Publish web service to a web server. This web service has a URL. If you are following RESTful approaches to web services, there would be unique URLs for resources available through the web. Each function that the web service performs uses one of the common HTTP verbs, e.g. GET and POST. You use "GET" to retrieve data from the web via the URL. You use "POST" when you also want to send data to the web.
From the client SDK (e.g. iOS, Android, Windows Mobile, Blackberry), build an HTTP request through the standard objects that are components of the SDK. Sometimes there are open-source libraries that provide wrapper classes that make this process easier. This HTTP request should either just use the URL (in the event you want to make a GET request), or you should build the request via the "body" of the request with the data that you want to send to the server, in the event of a POST request.
Both types of requests typically produce a response from the server, which you then handle and parse using objects and events that are typically components of the SDK.
You then do whatever you want with the parsed response in the context of the client.
Although the specifics of the implementation of this pattern can vary, the pattern is pretty consistent across all the major platforms; it's really the only way to do it.
I am currently working on a single-page web application. The web app will make calls to a REST-like API for authentication and data storage. We are currently in the middle of securing the application, and have worked out a strategy securing the site so only registered users can gain access. But one thing we also want to do is securing the API from others to write their own applications, or access it in any other way than through our web application. The problem from my view is that the API will be open for everybody and not only for my web application.
Anyone who knows how to do this, or who can point me in the right direction. Because right now, don't have a clue.
Considered using certificates and validation?
Your API should only be accessible, if the session of the client is authorized. That's pretty much anything you could do.
There are complex approaches like using client- and server-side encryption or something really basic: render a secret in your webpage that validates the user again on every request.
You could check the headers, where the original request comes from. And so on...
But as most of that is public in a users browser, anyone could read it and adopt it in a third party app.
So save yourself and the people that really want to do a third party app some time and provide a public API :)
Simplest way will be to use OAuth 2.0 ( supports both authentication and authorization) which you need.
Also ensure you secure the data on wire using TLS (HTTPS) and any of the options below
1. HTTP Digest
2. OAuthn 2.0
3. Certificates ( Shared secret)
Stick to HTTPS+Oauth2 for now.
You could lock down your you API to accept requests from known IP's. Also depending on how your network infrastructure is designed, your web application can sit in a DMZ and your API on an internal network accessible only by servers in your network, one of which will include your backend API (This article here info https://www.digitalocean.com/community/tutorials/5-common-server-setups-for-your-web-application has some tips). For better security, a secure network design in addition to an application security framework implementation like OAuth2 and HTTPS (mentioned above). For API's, I've found that resource based authorization works better than role based authorization. Lastly, constant review of your security setup is vital as things change all the time. A good approach to this is Threat Modelling described by OWASP here https://www.owasp.org/index.php/Application_Threat_Modeling
We don't exactly comply with the XML-RPC spec, but the concepts are nearly identical. A client comes in over HTTP/HTTPS with an XML payload. We respond with an XML payload answering the request. This is primarily machine to machine, so no human to type a username/password. Our construct runs within apache tomcat. We would like to authenticate the request and since not every service is available to every client, we need to authorize the request as well. We have both subscription and per use charging models so it is necessary to log everything.
What would you recommend for both server and client?
HTTP BASIC/DIGEST works fine for most machine to machine tasks, and it handled by the server so your API is unaffected.
It doesn't work as well for interactive uses because it's difficult to "log out" the user without closing the browser.
Otherwise you'll most likely need to alter your APIs to include authentication information and have your methods authenticate that within your code.
Or you could use the classic "login", set a cookie, keep a session technique.
But, frankly, for machine to machine work, HTTP BASIC is the easiest.
edit, regarding comments.
HTTP BASIC is simply a protocol used to present the artifacts necessary for authentication, and it works well for machine to machine web services.
HOW IT IS IMPLEMENTED is dependent on you and your application. Using Java, you can use container authentication and that will provide authentication as well as role mapping. The user -> role mapping is handled in either a data file or database. The URLs protected, and what roles are valid for each URL, is managed by web.xml.
If you continue to add different roles to different URLs, then, yes, you'll need to redeploy that application.
However, if you're just adding new users, then you simply update your file or database. And if you're adding new logic, and this new URLs, then you have to redeploy anyway. If you have a ROLE structure with a fine enough granularity, you won't have to be messing with the web.xml until you actually add new methods. For example you could, at the extreme, create a role per method, and assign them individually to users. Most don't need to go that far.
If you don't want to use container authentication, then write a Servlet Filter to implement your vision of mapping user and roles to URLs. You can still use the HTTP BASIC protocol for your clients, even if you implement your own facility.
If you're looking for an overall generic Java security framework, I defer to google -- there are several, I've not used any of them. I've had good luck with container authentication and writing our own.
#Will
I second the HTTP Basic suggestion, and can testify that it integrates fairly well with Spring Security, which I implemented on top of a legacy application that rolled its own DB-based authentication/authorization logic.