精通RESTful API设计与集成

需积分: 15 39 浏览量更新于2024-07-19 收藏 2.61MB PDF 举报

"Apress.Pro.RESTful.APIs.Design.Build.and.Integrate (2017) 是一本关于设计、构建和集成RESTful API的专著，作者Sanjay Patni详细介绍了如何利用REST、JSON、XML以及JAX-RS来创建高效且可扩展的API。本书适合开发者、架构师和IT专业人员阅读，旨在提升他们在API开发中的技能和理解。" 在当今互联网世界，RESTful API已经成为服务间通信的标准，它们提供了灵活、轻量级和可伸缩的接口。本书深入探讨了RESTful架构风格，这是Web服务设计的核心原则。REST（Representational State Transfer）强调无状态、客户端-服务器分离、缓存以及统一接口等概念，以实现高效的资源交互。书中详细讲解了如何设计RESTful API，包括定义资源、选择合适的HTTP方法（如GET、POST、PUT、DELETE等）、状态码和URI设计。此外，作者还讨论了使用超媒体作为应用程序状态的引擎（HATEOAS）这一RESTful架构的重要特性，以及如何在API设计中实现它。 JSON（JavaScript Object Notation）是RESTful API中最常用的表示数据格式，因为它简洁、易于解析，并且被大多数现代编程语言广泛支持。书中涵盖了JSON的结构、编码规范以及如何在API中有效使用JSON进行数据交换。 XML（eXtensible Markup Language）虽然在某些场景下不如JSON流行，但其强大的数据描述能力和与生俱来的验证机制使其在特定领域依然不可或缺。作者解释了如何在API中适当地使用XML，以及如何处理XML的解析和序列化。 JAX-RS（Java API for RESTful Web Services）是Java平台上的一个标准，用于简化RESTful服务的开发。通过使用JAX-RS，开发者可以轻松地创建出符合REST原则的服务端点。书中详细介绍了JAX-RS的关键组件，如注解（如@Path、@GET、@POST等）、消息体处理器和自定义提供者。除了这些核心概念，本书还涵盖了API版本控制、安全性、错误处理、性能优化和测试等方面。此外，还可能涉及API文档编写、使用Swagger等工具进行API的可视化，以及如何通过持续集成和交付来确保API的质量和可靠性。《Pro RESTful APIs》是一本全面介绍RESTful API设计和实现的实用指南，它不仅帮助读者理解RESTful架构的基本原理，还提供了实用的技巧和最佳实践，以便于开发者能够构建出高质量、易于维护的API系统。

Chapter 1 ■ Fundamentals oF restFul apIs

Table 1-1. SOAP vs. REST comparision

Topic SOAP REST

Origin SOAP (Simple Object Access

Protocol) was created in

1998 by Dave Winer etal. in

collaboration with Microsoft.

Developed by a large software

company, this protocol

addresses the goal of addressing

the needs of the enterprise

market.

REST (Representational State

Transfer) was created in 2000

by Roy Fielding at UC, Irvine.

Developed in an academic

environment, this protocol

embraces the philosophy of the

open Web.

Basic Concept Makes data available as services

(verb + noun), for example

“getUser” or “PayInvoice”

Makes data available as resources

(nouns), for example “user” or

“invoice”

Pros Follows a formal enterprise

approach

Works on top of any

communication protocol, even

asynchronously

Information about objects is

communicated to clients.

Security and authorization are

part of the protocol.

Can be fully described using

WSDL

Follows the philosophy of the

Open Web

Relatively easy to implement and

maintain

Clearly separates client and

server implementations

Communication isn’t controlled

by a single entity

Information can be stored by the

client to prevent multiple calls.

Can return data in multiple

formats (JSON, XML etc.)

Cons Spends a lot of bandwidth

communicating metadata

Hard to implement and is

unpopular among Web and

mobile developers

Only works on top of the HTTP

protocol

Hard to enforce authorization and

security on top of it

When to use When clients need to have

access to objects available on

servers

When you want to enforce a

formal contract between client

and server

When clients and servers operate

on a Web environment

When information about objects

doesn’t need to be communicated

to the client

When not to use When you want the majority of

developers to easily use your API

When your bandwidth is very

limited

When you need to enforce a

strict contract between client

and server

When performing transactions

that involve multiple calls

(continued)

Chapter 1 ■ Fundamentals oF restFul apIs

Table 1-1. (continued)

Topic SOAP REST

Use cases Financial services

Payment gateways

Telecommunication services

Social media services

Social networks

Web chat services

Mobile services

Examples https://www.salesforce.com/

developer/docs/api/ -

Salesforce SOAP API

https://developer.paypal.com/

docs/classic/api/

PayPalSOAPAPIArchitecture/

-Paypal SOAP API

https://dev.twitter.com/

https://developer.linkedin.

com/apis

Conclusion Use SOAP if you are dealing with

transactional operations and you

already have an audience that is

satisfied with this technology.

Use REST if you’re focused on

wide-scale API adoption or if your

API is targeted at mobile apps.

Web Architectural Style

According to Fielding, there are two ways to define a system.

• One is to start from a blank slate—an empty whiteboard—with no

initial knowledge of the system being built or the use of familiar

components until the needs are satisfied.

• A second approach is to start with the full set of needs for the

system, and constraints are added to individual components

until the forces that influence the system are able to interact in

harmony with each other.

REST follows the second approach. In order to define a REST architecture, a

null-state is initially defined—a system that has no constraints whatsoever and where

component differentiation is nothing but a myth—and constraints are added one by

one. The following subsections cover web architectural style constraints. Each of these

constrations defines how the framework for REST APIs should be architected and

designed. Security is another aspect which needs to be considered independently as part

of this framework when rolling out RESTful APIs to the end users.

Client-Server

The separation of concerns is the core theme of the Web’s client-server constraints.

The Web is a client-server-based system, in which clients and servers have distinct

parts to play.

They may be implemented and deployed independently, using any language or

technology, so long as they conform to the Web’s uniform interface.

Chapter 1 ■ Fundamentals oF restFul apIs

Uniform Resource Interface

The interactions between the Web’s components—meaning its clients, servers, and

network-based intermediaries—depend on the uniformity of their interfaces.

Web components interoperate consistently within the uniform interface’s four

constraints, which Fielding identified as:

• Identification of resources

• Manipulation of resources through representations

• Self-descriptive messages

• Hypermedia as the engine of application state (HATEOAS)

Layered System

Generally speaking, a network-based intermediary will intercept client-server

communication for a specific purpose.

Network-based intermediaries are commonly used for enforcement of security,

response caching, and load balancing

The layered system constraints enable network-based intermediaries such as proxies

and gateways to be transparently deployed between a client and server using the Web’s

uniform interface.

Caching

Caching is one of web architecture’s most important constraints. The cache constraints

instruct a web server to declare the cache ability of each response’s data.

Caching response data can help to reduce client-perceived latency, increase the

overall availability and reliability of an application, and control a web server’s load. In a

word, caching reduces the overall cost of the Web.

Stateless

The stateless constraint dictates that a web server is not required to memorize the

state of its client applications. As a result, each client must include all of the contextual

information that it considers relevant in each interaction with the web server.

Web servers ask clients to manage the complexity of communicating their

application state so that the web server can service a much larger number of clients. This

trade-off is a key contributor to the scalability of the Web’s architectural style.

Code-on-Demand

The Web makes heavy use of code-on-demand, a constraint which enables web servers to

temporarily transfer executable programs, such as scripts or plug-ins, to clients.

Chapter 1 ■ Fundamentals oF restFul apIs

Security

We have not covered security in this chapter as part of REST fundamentals, but security

is very important for rolling out RESTful APIs. This book has a complete chapter on

securing RESTful APIs which has details on best practices for securing RESTful APIs and

OAuth, which is a standard for REST APIs security.

What is REST?

We have briefly introduced REST with REST API fundamentals in the previous section.

This section has further introductory details about REST concepts.

“REST” was coined by Roy Fielding in his Ph.D. dissertation to describe a design

pattern for implementing networked systems. REST is Representational State Transfer, an

architectural style for designing distributed systems. It’s not a standard, but rather a set of

constraints. It’s not tied to HTTP, but is associated most commonly with it.

REST Basics

Unlike SOAP and XML-RPC, REST does not really require a new message format. The

HTTP API is CRUD (Create, Retrieve, Update, and Delete)

• GET = “give me some info” (Retrieve)

• POST = “here’s some update info” (Update)

• PUT = “here’s some new info” (Create)

• DELETE = “delete some info” (Delete)

• And more….

• PATCH = The HTTP method PATCH can be used to update partial

resources. For instance, when you only need to update one field of

the resource, PUTting a complete resource representation might

be cumbersome and utilizes more bandwidth.

• HEAD = The HEAD method is identical to the GET method,

except that the server must not return a message body in the

response. This method is often used for testing hypertext links for

validity, accessibility, and recent modification.

• OPTIONS = This method allows the client to determine the

options and/or requirements associated with a resource, or the

capabilities of a server, without implying a resource action or

initiating a resource retrieval.

• Notion of “Idempotency” – the idea that when sending a GET,

DELETE, or PUT to the system, the effect should be the same

whether the command is sent one or more times, but POST

creates an entity in the collection and therefore is not idempotent.

剩余135页未读，继续阅读

Andy__Han

粉丝: 50
资源: 14

精通RESTful API设计与集成

Apress.Pro.Ajax.and.Java.Frameworks.Jul.2006.HAPPY.NEW.YEAR.rar

Apress.Pro.Java.6.3D.Game.Development.Java.3D.JOGL.JInput.and.JOAL.APIs.Apr.2007

Apress.Pro.CSS.and.HTML.Design.Patterns.Apr.2007

Apress.Pro.iOS.Web.Design.and.Development.HTML5.CSS3.and.JavaScript.with.Safari

Apress.Pro.HTML5.and.CSS3.Design.Patterns

Apress.Pro.CSS.and.HTML.Design.Patterns.Apr.2007.rar（PDF）

Apress.Pro.JSF.and.Ajax

Apress.Pro.JSF.and.Ajax.pdf

[Apress.J2EE系列].Apress.Pro.JSP.2.4th.Edition.Dec.2005

Apress.Pro.Hibernate.and.MongoDB.Jul.2013

最新资源