PHP Web服务API开发全攻略（第2版）：构建现代应用桥梁

5星 · 超过95%的资源需积分: 9 162 浏览量更新于2023-06-02 收藏 10.8MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源推荐

The part of the URL after the ? is the “query string” and it’s one

way of passing additional data to a particular URL or endpoint.

In the story shown here, all the requests were made from the browser in response to a

user’s actions, although some occur behind the scenes, such as following redirects or

requesting additional assets. All the assets for a page, such as images, stylesheets, and

so on are fetched using separate requests that are handled by a server. Any content

that is loaded asynchronously (by JavaScript, for example) also creates more requests.

When we work with APIs, we get closer to the requests and make them in a more

deliberate manner, but the mechanisms are the same as those we use to make very

basic web pages. If you’re already making websites, then you already know all you

need to make web services!

Clients and Servers

Earlier in this chapter we talked about a request and response between a client and a

server. When we make websites with PHP, the PHP part is always the server. When

using APIs, we build the server in PHP, but we can consume APIs from PHP as well.

This is the point where things can get confusing. We can create either a client or a

server in PHP, and requests and responses can be either incoming or outgoing—or

both!

When we build a server, we follow patterns similar to those we use to build web

pages. A request arrives, and we use PHP to figure out what was requested and craft

the correct response. For example, if we built an API for customers so they could get

updates on their orders programmatically, we would be building a server.

Using PHP to consume APIs means we are building a client. Our PHP application

makes requests to external services over HTTP, and then uses the responses for its

own purposes. An example of a client would be a script that fetches your most recent

tweets and displays them.

It isn’t unusual for an application to be both a client and a server, as shown in

Figure 1-2. An application that accepts a request, and then calls out to other services

to gather the information it needs to produce the response, is acting as both a client

and a server.

When working on applications that are APIs or consume APIs,

take care with how you name variables involving the word

“request” to avoid confusion!

4 | Chapter 1: HTTP

Command-Line HTTP

cURL is a command-line tool available on all platforms. It allows us to make any web

request imaginable in any form, repeat those requests, and observe in detail exactly

what information is exchanged between client and server. In fact, cURL produced the

example output at the beginning of this chapter. It is a brilliant, quick tool for inspect‐

ing what’s going on with a web request, particularly when dealing with something

that isn’t in a browser or where you need to be more specific about how the request is

made. There’s also a cURL extension in PHP; we’ll cover that shortly in “Doing HTTP

with PHP” on page 12, but this section is about the command-line tool.

In its most basic form, a cURL request can be made like this:

curl http://requestb.in/example

We can control every aspect of the request to send; some of the most commonly used

features are outlined here and used throughout this book to illustrate and test the var‐

ious APIs shown.

If you’ve built websites before, you’ll already know the difference between GET and

POST requests from creating web forms. Changing between GET, POST, and other

HTTP verbs using cURL is done with the -X switch, so a POST request can be specifi‐

cally made by using the following:

curl -X POST http://requestb.in/example

There are also specific switches for GET, POST, and so on, but once you start working

with a wider selection of verbs, it’s easier to use -X for everything.

To get more information than just the body response, try the -v switch since this will

show everything: request headers, response headers, and the response body in full! It

splits the response up, though, sending the header information to STDERR and the

body to STDOUT:

$ curl -v -X POST http://requestb.in/example -d name="Lorna" -d

email="lorna@example.com" -d message="this HTTP stuff is rather excellent"

* Hostname was NOT found in DNS cache

* Trying 54.197.228.184...

* Connected to requestb.in (54.197.228.184) port 80 (#0)

> POST /example HTTP/1.1

> User-Agent: curl/7.38.0

> Host: requestb.in

> Accept: */*

> Content-Length: 78

> Content-Type: application/x-www-form-urlencoded

* upload completely sent off: 78 out of 78 bytes

< HTTP/1.1 200 OK

< Connection: keep-alive

* Server gunicorn/19.3.0 is not blacklisted

6 | Chapter 1: HTTP

< Server: gunicorn/19.3.0

< Date: Tue, 07 Jul 2015 14:49:57 GMT

< Content-Type: text/html; charset=utf-8

< Content-Length: 2

< Sponsored-By: https://www.runscope.com

< Via: 1.1 vegur

* Connection #0 to host requestb.in left intact

When the response is fairly large, it can be hard to find a particular piece of informa‐

tion while using cURL. To help with this, it is possible to combine cURL with other

tools such as less or grep; however, cURL shows a progress output bar if it realizes it

isn’t outputting to a terminal, which is confusing to these other tools (and to

humans). To silence the progress bar, use the -s switch (but beware that it also silen‐

ces cURL’s errors). It can be helpful to use -s in combination with -v to create output

that you can send to a pager such as less in order to examine it in detail, using a

command like this:

curl -s -v http://requestb.in/example 2>&1 | less

The extra 2>&1 is there to send the STDERR output to STDOUT so that you’ll see

both headers and body; by default, only STDOUT would be visible to less. With the

preceding command, you can see the full details of the headers and body, request and

response, all available in a pager that allows you to search and page up/down through

the output.

Working with the Web in general, and APIs in particular, means working with data.

cURL lets us do that in a few different ways. The simplest way is to send data along

with a request in key/value pairs—exactly as when a form is submitted on the Web—

which uses the -d switch. The switch is used as many times as there are fields to

include. To make a POST request as if I had filled in a web form, I can use a curl

command like this:

curl -X POST http://requestb.in/example -d name="Lorna"

-d email="lorna@example.com"

-d message="this HTTP stuff is rather excellent"

APIs accept their data in different formats; sometimes the data cannot be POSTed as a

form, but must be created in JSON or XML format, for example. There are dedicated

chapters in this book for working with those formats, but in either case we would

assemble the data in the correct format and then send it with cURL. We can either

send it on the command line by passing a string rather than a key/value pair to a sin‐

gle -d switch, or we can put it into a file and ask cURL to use that file rather than a

string (this is a very handy approach for repeat requests where the command line can

become very long). If you run the previous request and inspect it, you will see that the

body of it is sent as:

name=Lorna&email=lorna@example.com

Making HTTP Requests | 7

We can use this body data as an example of using the contents of a file as the body of

a request. Store the data in a file and then give the filename prepended with an @

symbol as a single -d switch to cURL:

curl -X POST http://requestb.in/example -d @data.txt

Working with the extended features of HTTP requires the ability to work with vari‐

ous headers. cURL allows the sending of any desired header (this is why, from a secu‐

rity standpoint, the header can never be trusted!) by using the -H switch, followed by

the full header to send. The command to set the Accept header to ask for an HTML

response becomes:

curl -H "Accept: text/html" http://requestb.in/example

Before moving on from cURL to some other tools, let’s take a look at one more fea‐

ture: how to handle cookies. Cookies will be covered in more detail in Chapter 4, but

for now it is important to know that cookies are stored by the client and sent with

requests, and that new cookies may be received with each response. Browsers send

cookies with requests as default behavior, but in cURL we need to do this manually by

asking cURL to store the cookies in a response and then use them on the next

request. The file that stores the cookies is called the “cookie jar”; clearly, even HTTP

geeks have a sense of humor.

To receive and store cookies from one request:

curl -c cookiejar.txt http://requestb.in/example

At this point, cookiejar.txt contains the cookies that were returned in the response.

The file is a plain-text file, and the way that a browser would store this information is

pretty similar; the data is just text. Feel free to open this file in your favorite text edi‐

tor; it can be amended in any way you see fit (which is another good reminder of why

trusting outside information is a bad idea; it may well have been changed), and then

sent to the server with the next request you make. To send the cookie jar, amended or

otherwise, use the -b switch and specify the file to find the cookies in:

curl -b cookiejar.txt http://requestb.in/example

To capture cookies and resend them with each request, use both the -b and -c

switches, referring to the same cookiejar file with each switch. This way, all incoming

cookies are captured and sent to a file, and then sent back to the server on any subse‐

quent request, behaving just as they do in a browser. This approach is useful if you

want to test something from cURL that requires, for example, logging in.

Another command-line tool well worth a mention here is HTTPie, which claims to

be a cURL-like tool for humans. It has many nice touches that you may find useful,

such as syntax highlighting. Let’s see some examples of the same kinds of requests

that we did with cURL.

8 | Chapter 1: HTTP

剩余179页未读，继续阅读

ramissue

粉丝: 354
资源: 1488

会员权益专享

PHP Web服务API开发全攻略（第2版）：构建现代应用桥梁

Wrox.Professional.JavaScript.for.Web.Developers.2nd.Edition.Jan.2009.pdf

Web.Scraping.with.Python.Collecting.Data.from.the.Modern.Web

Irresistible.APIs.Designing.web.APIs.that.developers.will.love

C# Web Services

项目报错：Field documentationCache in springfox.documentation.swagger2.web.Swagger2Controller required a bean of type 'springfox.documentation.spring.web.DocumentationCache' that could not be found.

(Java API for RESTful Web Services

org.springframework.web.servlet.DispatcherServlet.noHandlerFound No mapping for GET /https://fonts.googleapis.com/css怎么解决

142.250.98.90 translate.googleapis.com

1. Dependency 'androidx.appcompat:appcompat:1.4.1' requires libraries and applications that depend on it to compile against version 31 or later of the Android APIs. :app is currently compiled against android-29. Recommended acti

springboot+vue

springboot + jaxrs

".apis(RequestHandlerSelectors.basePackage("your.package.name")) "报错 需要的类型: com.google.common.base.Predicate <RequestHandler> 提供的类型: java.util.function.Predicate <RequestHandler>

restful api

Vue.config.productionTip = false Vue.use(http).use(ElementUI).use(dateUtil) Vue.prototype.Apis = Apis new Vue({ render: h => h(App), router, store }).$mount('#app')

天气预报Web服务实现C#

implement the shipping REST APIs with spring boot + sping mvc + jpa/batis + mysql + jwt

LLM-2307.04346.pdf

connect timed out. host=translate.googleapis.com

会员权益专享

最新资源

".apis(RequestHandlerSelectors.basePackage("your.package.name")) "报错需要的类型: com.google.common.base.Predicate <RequestHandler> 提供的类型: java.util.function.Predicate <RequestHandler>