互联网标准定义了 WMS 在分布式计算平台上的实现。它包括了支持超文本传输协议（HTTP）的 Internet 主机。因此，被服务器支持的每个操作的在线资源（Online Source）是一个 HTTP URL。每个操作的 URL 或者不同，或者一样，取决于服务提供者的判断。每个 URL 必须与 IETF RFC 2616 的描述一致，但是实现的方式是不同的。只有组成服务请求的请求部分在互联网标准中得到了定义。
WMS 1.3.0 支持两种请求方法：GET 和 POST。服务器可以提供其中一种或者两种方法。在不同的情形中在线资源的 URL 是不同的。对 GET 方法的支持是必须的，对 POST 方法的支持是可选的。
HTTP GET URLs 的保留字符
URL 标准（IETF RFC 2396）保留了部分意义重大且必须的字符，当这些字符与它们预定义的用法发生冲突时，这些字符就会转义。（注：在 SuperMap iServer 中，当请求参数中的字符与保留字符冲突时，iServer 将使用 UTF-8 编码机制，进行编码转换。）
OGC 标准详细解释了这些保留字符在 WMS 请求中的用法。
表1 WMS 请求字符串中的保留字符
| 字符 | 保留用法 |
| ? | 表示请求字符串开始的分隔符。 |
| & | 请求字符串中参数之间的分隔符。 |
| = | 参数名称和值之间的分隔符。 |
| , | 一个参数列表中不同参数值之间的分隔符（比如 GetMap 请求中的 BBOX, LAYERS,STYLES ）。 |
| + | 空格的快速表示。 |
HTTP GET
WMS 必须支持 HTTP 协议中的 “GET” 方法。
HTTP GET 请求对应的在线资源 URL 实际上只是一个 URL 的前缀，必须给这个前缀增加一些额外的参数是，这样才能构建一个合法操作请求。URL 前缀的定义是和 IETF RFC 2396 中的定义一致的。它是一个字符串，依次包含了模式（“http”或“https”），互联网协议主机名或者 IP 地址，可选的端口号，路径，必须的英文问号“?”，以及可选的字符串。这个字符串由一个或者多个服务指定参数，这些参数以“&”结尾。这个前缀定义了某一操作向特定服务器发送请求消息的网络地址。每个操作可能有不同的前缀，这完全取决于服务提供者。
互联网标准定义了怎样创建一个附加到 URL 前缀的请求部分，这样可以形成一个完整的请求信息。每个 WMS 操作都有一些必需的或者可选请求参数。每个参数都有自己的名称，一个或者多个合法值（合法值的定义是在服务元数据的基础上通过互联网标准或者由用户自己来选择）。为了使 URL 请求部分模式化，客户端应该附加必需参数，以及其它任何要用到的可选参数，这些参数都要以名-值对（“name=value&”）的形式出现。“&”是名值对之间的分隔符，因此在最后一个请求字符串后它是可选的。
使用 HTTP GET 方法时，服务器定义了附加到 URL 前缀中的客户端构建请求部分，HTTP 调用完整的 URL。
下表总结了一个操作请求 URL 的组成。
表2 使用 HTTP GET 操作时，WMS 请求的组成结构
| URL 组成 | 描述 |
| http://host[:port]/path[?{name[value]&}] |
服务操作的 URL 前缀。 []表示可选部分，出现0次或1次。 { }表示出现0次或1次。 |
| Name=value& | 由 OGC Web 服务定义的一个或多个标准请求参数，采用参数名/值成对的形式。OWS 规范定义了每一种操对应的参数。 |
HTTP POST
WMS 支持 HTTP 协议的 POST 方法。
HTTP POST 请求的在线资源 URL 是一个完整有效的 URL，而不像 HTTP GET 中仅是个前缀。客户端可以把 POST 消息体转换成 URL。用户要为操作请求构建一个有效目标时，WMS 1.3.0 并不要求把额外的请求参数附加到 URL 中。使用 POST 请求时，请求信息以 XML 文档的形式表达。