精通RESTful API设计：构建与集成REST、JSON、XML和JAX-RS

3星 · 超过75%的资源需积分: 9 9 浏览量更新于2024-07-20 2 收藏 2.61MB PDF 举报

"Pro.RESTful.APIs.Design.Build.and.Integrate.with.REST.JSON.XML.and.JAX-RS.pdf" 是一本由Sanjay Patni编著的专业书籍，旨在教授读者如何设计、构建和集成RESTful API，涉及REST、JSON、XML以及JAX-RS等技术。这本书基于作者在UC Santa Cruz硅谷开设的课程，涵盖了从架构到设计再到编码的全面知识，适合有经验的web程序员和开发者阅读。在书中，读者将学习以下关键知识点： 1. RESTful APIs基础：理解REST（Representational State Transfer）的核心原则，包括状态转移、无状态性和统一接口等。REST是一种架构风格，常用于构建分布式系统，尤其是Web服务。 2. API设计与建模：了解如何设计优雅、易于理解和使用的API接口。这包括资源的命名、URI的设计、HTTP方法的选择以及状态码的正确使用。 3. XML与JSON：深入理解这两种数据交换格式。XML是一种结构化数据格式，适用于复杂的文档存储；JSON则更轻量级，通常用于Web服务中的数据传输，因其简洁和易于解析而被广泛采用。 4. JAX-RS介绍：JAX-RS（Java API for RESTful Web Services）是Java平台上的RESTful服务开发标准。学习如何利用JAX-RS创建、处理HTTP请求和响应，以及如何定义资源、注入依赖和错误处理。 5. API组合与框架：掌握如何构建API组合，理解API版本控制的重要性，并探索使用不同框架（如Spring Boot或Jersey）来简化REST服务的实现。 6. API平台与数据处理：探讨API背后的基础设施，包括API网关、微服务架构和数据处理策略，以及如何选择合适的工具和技术栈。 7. API管理与客户端：学习API管理实践，包括API文档、测试、监控和API客户端的开发，以确保API的稳定性和可用性。 8. API安全与缓存：讨论API的安全措施，如身份验证、授权和加密，以及如何有效地实现缓存策略以提高性能。这本书适合对RESTful API有一定了解，希望通过实例和案例研究深化理解，以及希望在微服务、大数据应用和Web服务领域提升技能的开发者。通过阅读，读者可以遵循最佳实践来构建健壮且可扩展的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页未读，继续阅读

ramissue

粉丝: 354
资源: 1487

精通RESTful API设计：构建与集成REST、JSON、XML和JAX-RS

Designing Web APIs

Pro RESTful APIs Design Build and Integrate with REST JSON XML and JAX-RS 无水印pdf

The-Complete-Guide-to-Build-RESTful-APIs-with-Node.js

Api-securing-restful-apis-with-jwt.zip

jackson-jaxrs-json-provider-2.2.4.zip

ws-jax-rs-rest:带有 JAX-RS 的基本 RESTful Web 服务

JAX-WS-and-JAX-RS-Web-Services-integrated-with-JPA

jax-rs.github.io:jax-rs网站

RESTful-Web-API-Design-with-Node.js-12-contact-api

RESTful-Web-API-Design-with-Node.JS-Second-Edition:RESTful Web API设计与Node.JS第二版代码

最新资源