基于ColdFusion中的REST的网站 [英] Website based on REST in ColdFusion

问题描述

我的公司即将从头开始重新设计一个大型项目。我们目前正在考虑如何实现数据提供者。我在过去几个月里曾经整合过一些网络服务，很像这样处理数据。所以我在想一个RESTful设计。我们将使用ColdFusion 10附带的REST支持，但我实际上不喜欢它所需的组件结构。

My company is about to redesign a big project from scratch. We are currently thinking about how to implement data providers. I used to integrate some webservices in the last few months and pretty much like handling data this way. So I was thinking about a RESTful design. We will be using ColdFusion 10 that comes with REST support, but I actually don't like the component structure required for it.

最大的优势可能是，能够使用REST为我们的所有平台提供数据，即：网站，移动网站和iOS / Android应用程序。我的安全方法如下：
公开数据可以由任何人访问（显然）。
私人数据只能通过BasicAuth访问。
使用BasicAuth还允许我们拥有具有不同访问级别的用户角色。授权将是隐式的，并基于会话/登录。

The biggest advantage is probably that we'll be able to use REST to provide data for all our platforms, that is: website, mobile website and iOS/Android app. My security approach would be as follow: Public data can be accessed by anyone (obviously). Private data can be accessed with BasicAuth only. Using BasicAuth also allows us to have user roles with different access levels. The authorization will be implicit and based on the session/login.

<!--- server-side example to request customer information (private data, BasicAuth required) --->
<cfset requestedID = 123>
<cfhttp url="/customer/#requestedID#" method="get" username="#APPLICATION.REST_SYSTEMUSER#" password="#APPLICATION.REST_SYSTEMUSER_PW#">
    <cfhttpparam type="url" name="includeAddresses" value="true">
</cfhttp>

<!--- successful response in JSON --->
{
    "ID": 123,
    "FirstName": "John",
    "LastName": "Doe",
    "Birthday": "1970-01-01",
    "BillingAddress": {
        "Receiver": "John Doe",
        "Street": {
            "Name": "Main Street",
            "Number": "13",
            "Addition": ""
        }
        "City": {
            "ZipCode": "AB-123",
            "Name": "Sampletown",
            "District": ""
        }
    },
    "ShippingAddresses": [
    ]
}

<!--- deserialize JSON and build an object to use server-side (the constructor wraps the data and adds functions to it) --->
<cfset customerJSON = deserializeJSON(CFHTTP.FileContent)>
<cfset customer = createObject("component", "Customer").init(customerJSON)>

这是我想到的问题：

1. 在每个页面上使用这种通用的REST方法来处理
   上的所有事情是否聪明？ （在网站上使用REST可以开始使用REST吗？）


2. 执行本地HTTP请求会影响性能并减慢页面
   的负载吗？


3. BasicAuth是否足以保护数据？ （我只是添加了一些小的
   安全功能，例如请求垃圾邮件保护）


4. 最好避免在webservice中有依赖关系，如
   / customer / 访问 / address / 以接收其数据？

1. Is it smart to use this general REST approach for everything on every single page? (Is it smart to use REST on websites to begin with?)
2. Do local HTTP requests impact performance and slow down page loading?
3. Is BasicAuth sufficient to protect the data? (I would just add minor security features such as request-spam-protection to it)
4. Is it best to avoid having dependencies within the webservice like /customer/ accessing /address/ to receive its data?

在其他一些（旧的）网站上，我们有基于文件的数据提供程序（包括数据库访问等的组件和组件），但是我们在更复杂的页面作为检查过程）通过包括，不透明和重的组件，混合模型/视图/控制器元素等名称冲突。

On some of the other (older) website we have file based data providers (includes and components that take care of database access etc.), but we experienced several issues with the more complex pages (such as a checkout process) like name conflicts through includes, intransparent and heavy components, mixing up model/view/controller elements etc.

推荐答案

这是我的答案，基于我最近做的研究。我的公司正在寻找新的产品开发，所以我一直在问自己相同的问题。我们也非常受到REST API的概念的吸引，REST API不仅能够使前端实现，而且还能成为其他应用程序的集成点。我们为其他产品维护了一个单独的API，如果您不小心，它很容易与主应用失去同步。

Here's my answers, based on the research I've done recently. My company is looking at new product development, so I've been asking a lot of the same questions as yourself. We're also very attracted by the notion of a REST API being not only something that enables the front-end but in it also becoming an integration point for other applications. We've maintained a separate API for other products and it's all too easy for it to loose sync with the main App if you're not careful.

1. 使用REST /单页方法很聪明吗？当然可以。一些大型网站像这样工作。看起来很常见的是混合方法，其中服务器可以为初始页面生成HTML，可能显示10个产品），但是移动到接下来的10个产品将通过RESTful调用和客户端呈现。这可能会为您提供最好的客户体验，但是以构建两个不同的模板（服务器端模板，以及客户端模板）的微小成本。根据您的网站的工作原理和使用方式，可能需要也可能不需要。例如，GMail是一个单页应用程序，但它是一个应用程序，你可以忍受它花费的几秒钟显示一个加载栏，而运行零售网站，这种滞后可能是不可接受的。

1. Is it smart to use the REST/Single-Page approach? It certainly can be. A number of large sites work like this. What does seem to be common is a hybrid approach where the server may generate the HTML for the initial page, perhaps with 10 products shown), but moving to the next 10 products will be via a RESTful call, with client-side rendering. This probably gets you the best possible customer experience, but at the slight cost of building two different templates (the server-side one, as well as the client-side one). Depending on how your site works and who uses it, this may or may not be needed. For example, GMail is a single-page app, but it's an app and you tolerate the couple of seconds it spends showing you a loading bar, whereas running a retail site, this kind of lag may not be acceptable.

本地请求是否减缓加载速度？你的意思是让你的网站进行REST调用来获取它的数据，而不是直接到数据库？在这种情况下，它会增加一些延迟，因为涉及到额外的网络跳跃，但是在一个良好的系统和部署，我认为滞后可能是可控的。

Do local requests slow down loading? Do you mean having your website making REST calls to get it's data, rather that going straight to database? In which case, it will add some latency, as there's an extra network hop involved, but in a well set up system and deployment, I'd think that lag may be manageable.

HTTP基本。我只会考虑它通过HTTPS。它只是不够安全通过HTTP。

HTTP-basic. I'd only consider it over HTTPS. It's just not secure enough over HTTP. This is covered in the presentation I link to below.

依赖数据。我也想知道这一点。我一直非常有帮助的是观看来自StormPath的演示，其中涉及了很多问题，实现RESTful API时的良好做法。它们包括一种链接数据的方法（遵循HATEOAS原则），但也包括实体扩展，因此GET到 / customers / ID123？expand = address 将返回客户的表示，但它们的地址嵌入，这是一个很好的方式，以避免多次往返，以获得所需的所有数据。

Dependent data. I was wondering about that too. What I round very helpful was watching the presentation from StormPath, which covered a lot of concerns and good practices when implementing a RESTful API. They cover an approach for linking the data (following HATEOAS principles) but also entity expansion, so a GET to /customers/ID123?expand=address would return a representation of the customer, but with their Address embedded, which is a nice way of avoiding multiple round-trips to get all the data you need.

关于CF10的REST支持。我看着它，并不是所有的热衷于它是如何工作的。我可能误解了它，但REST应用程序似乎与任何类型的常规应用程序，你试图混合在一起非常分离。 Railo的实现看起来很相似，但是有些微不同的黑色。当然，构建一个工作的两个REST应用程序似乎很棘手。您看过 Taffy 吗？

Regarding CF10's REST support. I looked at it and wasn't all that keen on how it worked. I may have misunderstood it, but the REST app seemed to be very separated from any kind of regular app you were trying to hybrid alongside. The Railo implementation seemed pretty similar, but with slightly different niggles. Certainly, building a REST app which worked on both seemed pretty tricky. Have you looked at Taffy at all? I've not, but would be interested in how it works.

因为REST是一种建筑风格，而不是一个严格的标准，所以有很多纬度你实现的东西和很多的范围争论/论'最好的​​方法

Because REST is an architectural style, rather than a strict standard, there's a lot of latitude for exactly how you implement things and a lot of scope for debate/argument on the 'best' approach

这篇关于基于ColdFusion中的REST的网站的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！