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

问题描述

我的公司即将从头开始重新设计一个大项目.我们目前正在考虑如何实现数据提供者.在过去的几个月里，我曾经集成一些 Web 服务，并且非常喜欢以这种方式处理数据.所以我在考虑一个 RESTful 设计.我们将使用带有 REST 支持的 ColdFusion 10，但我实际上不喜欢它所需的组件结构.

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 开始是否明智?和?)
2. 本地 HTTP 请求是否会影响性能并降低页面速度正在加载?
3. BasicAuth 是否足以保护数据?(我只会添加次要安全功能，例如请求垃圾邮件保护)
4. 最好避免在 web 服务中存在依赖关系，例如/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 的概念也非常吸引我们，它不仅可以支持前端，而且还可以成为其他应用程序的集成点.我们为其他产品维护了一个单独的 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 原则)以及实体扩展，因此对 /customers/ID123?expand=address 的 GET 将返回客户的表示，但嵌入了他们的地址，这是避免多次往返以获取所需数据的好方法.

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屋！