restful服務
㈠ RESTful WebService和web service的區別
restful是一種架構風格，其核心是面向資源；而webService底層SOAP協議，主要核心是面向活動。
SOAP：簡單對象訪問協議，很輕量，同時作為應用協議可以基於多種傳輸協議來傳遞消息（Http,SMTP等）。
客戶端和服務器端的通訊方式
總結：
REST對於資源型服務介面來說很合適，同時特別適合對於效率要求很高，但是對於安全要求不高的場景。而SOAP的成熟性可以給需要提供給多開發語言的，對於安全性要求較高的介面設計帶來便利。所以我覺得純粹說什麼設計模式將會占據主導地位沒有什麼意義，關鍵還是看應用場景。成熟度SOAP雖然發展到現在已經脫離了初衷，但是對於異構環境服務發布和調用，以及廠商的支持都已經達到了較為成熟的情況。不同平台，開發語言之間通過SOAP來交互的web service都能夠較好的互通。
㈡ 如何在Java客戶端調用RESTful服務
public static void main(String[] args) { Store store = new Store();// 准備參數來 // 首先創建一個webservice客戶端自，參數依次為：webservice的url, webservice的名稱, webservice的方法, 參數列表, 返回類型, 泛型的類型(不需要泛型就傳入null) WebserviceClient client = new WebserviceClient(", "store", "find", new Object[] { store }, List.class, Store.class); List<Store> list = client.execute();// 調用webservice System.out.println("從伺服器返回" + list.size() + "個商品");// 得到了服務端返回的數據 }
㈢ 怎麼實現一個可配置的RESTful服務
DELETE方法是用來刪除URL所指定的資源的，作為HTTP協議規定的方法之一，當然可以被使用，只是需要注意下面的一些細節，避免系統設計意外。
1、具體實現上，伺服器可能會有自己變通的處理方式，比如出於安全、數據完整性的考慮，把`刪除`轉義為`禁用`，畢竟刪除數據是危險的，需要意識到這一點
2、提交DELETE請求時，不能包含Entity Body。排除傳輸編碼的要求，Entity Body實際上就是HTTP消息體：
The message-body (if any) of an HTTP message is used to carry the entity-body associated with the request or response.
The message-body differs from the entity-body only when a transfer-coding has been applied,
message-body = entity-body
| <entity-body encoded as per Transfer-Encoding>
㈣ 如何通過類對象作為方法參數的RESTful服務嗎
需要在對象前聲明 @ApiBodyObject
@POST
@Path("/addFavor/")
void addFavor(@QueryParam("linkId") String linkId, @ApiBodyObject User user,
@QueryParam("favorTypeCode") String favorTypeCode, @QueryParam("linkTable") String linkTable);
@ApiBodyObject 相當於 SpringMVC 的 @RequestBody
參數註解的作用就是將專 xml/json (具體那種看配置，cxf 是json) 轉換為實體對象屬如 User 傳遞給實現方法，如下：
@Override
@Transactional(readOnly = false)
public void addFavor(String linkId, User user, String favorTypeCode, String linkTable) {
}
㈤ java web 怎麼對外提供restful服務
請求和響應都是基於資源表示的傳輸來構建的。資源是通過全局ID來標識的，這些ID一般使用的是一個統一資源標識符（URI）
㈥ 如何在Java客戶端調用RESTful服務
如何在Java客戶端調用RESTful服務
public static void main(String[] args) {
Store store = new Store();// 准備參數
// 首先創建一個webservice客戶端，參內數依次為：webservice的url, webservice的名稱, webservice的方法, 參數列表, 返回類容型, 泛型的類型(不需要泛型就傳入null)
WebserviceClient client = new WebserviceClient(", "store", "find", new Object[] { store }, List.class, Store.class);
List<Store> list = client.execute();// 調用webservice
System.out.println("從伺服器返回" + list.size() + "個商品");// 得到了服務端返回的數據
}
把里邊鏈接和參數換掉
㈦ RESTful WebService和web service的區別
一個最簡單web服務就一個web頁面等待請求與處理。更容易理解的方式是Web
Service可以把一個應用變成一個基本WEB方式的請求與處理的應用。常見的兩種
Web Service處理方式為：
a. 基於WSDL/SOAP的方式
b. Rest方式
方式a是比較正統的，客戶端調用必須先取得WSDL文件，然後生成調用的API才可
以使用。它不是我要說的重點，基本調用流程如下：
方式b是Rest方式，Rest的Web Service的設計原則是基於CRUD，其支持四種操作分
別為：
GET – 獲取信息/請求信息內容，絕大多數瀏覽器獲取信息時使用該方式。
POST – 增加信息內容，顯示以前的信息內容，可以看作是insert操作
PUT – 更新信息內容，相當與update
DELETE – 刪除信息內容可以看作是delete
Rest方式更加簡單便捷，如果從設計原則上看HTTP協議本身已經是最Restful風格的
協議了HTTP協議很好的支持了CRUD的操作。正是因為如此，WEB2.0以來, 基於
Restful的Web Service越來越多的成為首選。
二：認識RestfulStyle
Rest的全稱是可表述狀態遷移(RepresentationalState Transfer), 可能從字面看有點奇怪
HTTP協議本身無狀態協議，其保持連接通過設置請求頭欄位Connection: keep-alive與
設置過期時間來同時控制。其實Rest方式的WebService也是無狀態的這樣做的好處最少
有以下兩個：
1. 更好的負載平衡，減輕伺服器端負擔
2. 更快的客戶端響應，減少不必要的狀態檢查。
Restful 風格的興起，要感謝互聯網巨頭Google,Facebook等他們提供大量基於Restful
風格的web服務，從谷歌地圖到天氣預報到翻譯，國內的互聯網巨頭騰訊，新浪微博也
發布自己的web服務，吸引更多的開發者加入他們的陣營。Rest除了滿足基本的CRUD
設計原則之外，還要遵循如下約定：
1. 資源操作可以通過描述來實現即Representation
2. 消息本身是無狀態與自我描述(傳輸支持XML與JSON)
3. 可以發送與接受多個Representation
Rest風格(Restful Style)架構原則：
1. 客戶伺服器方式
2. 無狀態協議傳輸
3. 支持緩存
4. 統一介面定義
5. 分層系統設計
這樣發布了Rest的Web服務API其改變不會影響到客戶端程序與實現。如果你的系統
不能適用Rest風格的架構怎麼辦，重新設計一個新的架構，擴展Rest風格架構。但是
這個世界上絕大數的系統與應用要做的事情就是CRUD。
三. Rest與HTTP
上面已經提到過HTTP協議可能是最Rest風格的協議，而HTTP1.1協議設計的一個原則
就要實現Rest風格。所以毫無疑問HTTP的GET, POST, PUT, DELETE就是最好的證明
但是Rest風格是否可以應用到其它一些協議與系統設計中嘛，答案是肯定的，一個最好
的例子證明就POP3協議, POP3支持Fetch 數據記錄，查詢記錄，更新記錄與刪除記錄
(記錄代表email)多麼完美的Rest風格協議。
已經存在的HTTP協議應用：
1. 瀏覽器客戶端(你天天上網，不是IE就是Chrome，或者其它瀏覽器，你懂的)
2. 即時消息通信，MSN/Skype支持
3. 各種內容管理系統
4. 博客系統與微博客戶端應用。
5. 你可以來補充/？
㈧ 怎麼通過url向一個restful服務發出delete請求
DELETE方法是用來刪除URL所指定的資源的，作為HTTP協議規定的方法之一，當然可以被使用，只是需要注意下面的一些細節，避免系統設計意外。
1、具體實現上，伺服器可能會有自己變通的處理方式，比如出於安全、數據完整性的考慮，把`刪除`轉義為`禁用`，畢竟刪除數據是危險的，需要意識到這一點
2、提交DELETE請求時，不能包含Entity Body。排除傳輸編碼的要求，Entity Body實際上就是HTTP消息體：
The message-body (if any) of an HTTP message is used to carry the entity-body associated with the request or response.
The message-body differs from the entity-body only when a transfer-coding has been applied,
message-body = entity-body
| <entity-body encoded as per Transfer-Encoding>
對於GET/POST/PUT方法，傳遞Entity Body都不會有問題，但對於DELETE方法，由於該方法傳遞Entity Body沒有明確定義的語義，所以有些伺服器實現會丟棄/忽略DELETE請求的entity body，或者拒絕該請求。參見HTTP協議草稿（http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-22#page-28）4.3.5 DELETE章節：
A payload within a DELETE request message has no defined semantics;
sending a payload body on a DELETE request might cause some existing
implementations to reject the request.
注意（過時的）老版本的RFC2616（http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.3）裡面沒有特別說明這一點。
3、PUT/DELETE方法從語義上來講，對資源是有破壞性的，PUT更改現有的資源，而DELETE摧毀一個資源，帶有破壞性質的方法有時候會被防火牆或者IT管理人員特別關注，所以當提供PUT/DELETE介面服務時，需要確保伺服器前置的防火牆沒有block這些方法。當然如果走的是HTTPS協議，無需擔心這一點。
java中使HttpDelete可以發送body信息
RESTful api中用到了DELETE方法，android開發的同事遇到了問題，使用HttpDelete執行DELETE操作的時候，不能攜帶body信息，研究了很久之後找到了解決方法。 我們查看httpclient-4.2.3的源碼可以發現，methods包下麵包含HttpGet, HttpPost, HttpPut, HttpDelete等類來實現http的常用操作。 其中，HttpPost繼承自，類又實現了HttpEntityEnclosingRequest介面，實現了setEntity的方法。 而HttpDelete繼承自HttpRequestBase，沒有實現setEntity的方法，因此無法設置HttpEntity對象。 這樣解決方法就明顯了，我們可以自己實現一個MyHttpDelete類，繼承自，覆蓋其中的getMethod方法，使其返回「DELETE」。
public class MyHttpDelete extends {
public static final String METHOD_NAME = "DELETE";
public String getMethod() {
return METHOD_NAME;
}
public MyHttpDelete(final String uri) {
super();
setURI(URI.create(uri));
}
public MyHttpDelete(final URI uri) {
super();
setURI(uri);
}
public MyHttpDelete() {
super();
}
}
使用delete方法時，直接可以按下面方式操作
DefaultHttpClient httpClient = new DefaultHttpClient();
MyHttpDelete delete = new MyHttpDelete("http://url.com");
List<NameValuePair> nameValuePairs = new ArrayList<NameValuePair>();
delete.setEntity(new UrlEncodedFormEntity(nameValuePairs));
HttpResponse response = httpClient.execute(delete);
㈨ 如何在Java中 提供 RESTful Web 服務
通過REST風格體系架構，請求和響應都是基於資源表示的傳輸來構建的。資源是通過全局ID來標識的，這些ID一般使用的是一個統一資源標識符（URI）。客戶端應用使用HTTP方法（如，GET、POST、PUT或DELETE）來操作一個或多個資源。通常，GET是用於獲取或列出一個或多個資源，POST用於創建，PUT用於更新或替換，而DELETE則用於刪除資源。
例如，GET http //host/context/employees/12345將獲取ID為12345的員工的表示。這個響應表示可以是包含詳細的員工信息的XML或ATOM，或者是具有更好UI的JSP/HTML頁面。您看到哪種表示方式取決於伺服器端實現和您的客戶端請求的MIME類型。
RESTful Web Service是一個使用HTTP和REST原理實現的Web Service。通常，一個RESTful Web Service將定義基本資源URI、它所支持的表示/響應MIME，以及它所支持的操作。
本文將介紹如何使用Spring創建Java實現的伺服器端RESTful Web Services。這個例子將使用瀏覽器、curl和Firefox插件RESTClient作為發出請求的客戶端。
本文假定您是熟悉REST基本知識的。
Spring 3的REST支持
在Spring框架支持REST之前，人們會使用其他幾種實現技術來創建Java RESTful Web Services，如Restlet、RestEasy和Jersey。Jersey是其中最值得注意的，它是JAX-RS（JSR 311）的參考實現。
Spring是一個得到廣泛應用的Java EE框架，它在版本3以後就增加了RESTful Web Services開發的支持。雖然，對REST的支持並不是JAX-RS的一種實現，但是它具有比標準定義更多的特性。REST支持被無縫整合到Spring的MVC層，它可以很容易應用到使用Spring構建的應用中。
Spring REST支持的主要特性包括：
注釋，如@RequestMapping 和 @PathVariable，支持資源標識和URL映射
支持為不同的MIME/內容類型使用不同的表示方式
使用相似的編程模型無縫地整合到原始的 MVC 層
創建一個示例RESTful Web Service
本節中的例子將演示Spring 3環境的創建過程，並創建一個可以部署到Tomcat中的「Hello World」應用。然後我們再完成一個更復雜的應用來了解Spring 3 REST支持的重要概念，如多種MIME類型表示支持和JAXB支持。另外，本文還使用一些代碼片斷來幫助理解這些概念。
Hello World：使用Spring 3 REST支持
要創建這個例子所使用的開發環境，您需要：
IDE：Eclipse IDE for JEE (v3.4+)
Java SE5 以上
Web 容器：Apache Tomcat 6.0（Jetty或其他容器也可）
Spring 3框架（v3.0.3是本文編寫時的最新版本）
其他程序庫：JAXB 2、JSTL、commons-logging
在 Eclipse 中創建一個Web應用，然後設置Tomcat 6作為它的運行環境。然後，您需要設置web.xml文件來激活Spring
WebApplicationContext。這個例子將Spring bean配置分成兩個文件：rest-servlet.xml 包含與MVC/REST有關的配置，rest-context.xml包含服務級別的配置（如數據源 beans）。清單 1 顯示了web.xml中的Spring配置的部分。
清單 1. 在web.xml中激活Spring WebApplicationContext
以下是引用片段：
contextConfigLocation
/WEB-INF/rest-context.xml
<!-- This listener will load other application context file in addition to
rest-servlet.xml -->
org.springframework.web.context.ContextLoaderListener
rest
org.springframework.web.servlet.DispatcherServlet
1
rest
/service/*
在rest-servlet.xml文件中創建Spring MVC的相關配置（Controller、View、View Resolver）。清單 2 顯示了其中最重要的部分。
清單 2. 在rest-servlet.xml文件中創建Spring MVC配置
以下是引用片段：
<bean class="org.springframework.web.servlet.mvc.annotation
." />
<bean class="org.springframework.web.servlet.mvc.annotation
." />
<bean id="jaxbMarshaller"
class="org.springframework.oxm.jaxb.Jaxb2Marshaller">
dw.spring3.rest.bean.Employee
dw.spring3.rest.bean.EmployeeList
<bean id="employees" class=
"org.springframework.web.servlet.view.xml.MarshallingView">
<bean id="viewResolver" class=
"org.springframework.web.servlet.view.BeanNameViewResolver" />
上面的代碼中：
Component-scan啟用對帶有Spring注釋的類進行自動掃描，在實踐中，它將檢查控制器類中所定義的@Controller注釋。
和使用@ReqeustMapping注釋的類或函數的beans由Spring處理這個注釋將在下一節進行詳細介紹。
Jaxb2Mashaller定義使用JAXB 2進行對象XML映射（OXM）的編組器（marshaller）和解組器（unmarshaller ）
MashallingView定義一個使用Jaxb2Mashaller的XML表示view
BeanNameViewResolver使用用戶指定的bean名稱定義一個視圖解析器
本例將使用名為「employees」的MarshallingView。
這樣就完成了Spring的相關配置。下一步是編寫一個控制器來處理用戶請求。清單3顯示的是控制器類。
㈩ spring mvc 提供的restful 服務怎麼訪問
Spring MVC本身對支持非常好。它的@RequestMapping、@RequestParam、@PathVariable、@ResponseBody註解很好的支持了REST。18.2 Creating RESTful services
1. @RequestMapping
Spring uses the @RequestMapping method annotation to define the URI Template for the request. 類似於struts的action-mapping。 可以指定POST或者GET。
2. @PathVariable
The @PathVariable method parameter annotation is used to indicate that a method parameter should be bound to the value of a URI template variable. 用於抽取URL中的信息作為參數。（注意，不包括請求字元串，那是@RequestParam做的事情。）
@RequestMapping("/owners/{ownerId}", method=RequestMethod.GET)
public String findOwner(@PathVariable String ownerId, Model model) {
// ...
}
如果變數名與pathVariable名不一致，那麼需要指定：
@RequestMapping("/owners/{ownerId}", method=RequestMethod.GET)
public String findOwner(@PathVariable("ownerId") String theOwner, Model model) {
// implementation omitted
}
Tip
method parameters that are decorated with the @PathVariable annotation can be of any simple type such as int, long, Date... Spring automatically converts to the appropriate type and throws a TypeMismatchException if the type is not correct.
3. @RequestParam
官方文檔居然沒有對這個註解進行說明，估計是遺漏了（真不應該啊）。這個註解跟@PathVariable功能差不多，只是參數值的來源不一樣而已。它的取值來源是請求參數（querystring或者post表單欄位）。
對了，因為它的來源可以是POST欄位，所以它支持更豐富和復雜的類型信息。比如文件對象:
@RequestMapping("/imageUpload")
public String processImageUpload(@RequestParam("name") String name,
@RequestParam("description") String description,
@RequestParam("image") MultipartFile image) throws IOException {
this.imageDatabase.storeImage(name, image.getInputStream(),
(int) image.getSize(), description);
return "redirect:imageList";
}
還可以設置defaultValue：
@RequestMapping("/imageUpload")
public String processImageUpload(@RequestParam(value="name", defaultValue="arganzheng") String name,
@RequestParam("description") String description,
@RequestParam("image") MultipartFile image) throws IOException {
this.imageDatabase.storeImage(name, image.getInputStream(),
(int) image.getSize(), description);
return "redirect:imageList";
}
4. @RequestBody和@ResponseBody
這兩個註解其實用到了Spring的一個非常靈活的設計——HttpMessageConverter 18.3.2 HTTP Message Conversion
與@RequestParam不同，@RequestBody和@ResponseBody是針對整個HTTP請求或者返回消息的。前者只是針對HTTP請求消息中的一個 name=value 鍵值對(名稱很貼切)。
HtppMessageConverter負責將HTTP請求消息(HTTP request message)轉化為對象，或者將對象轉化為HTTP響應體(HTTP response body)。
public interface HttpMessageConverter<T> {
// Indicate whether the given class is supported by this converter.
boolean supports(Class<? extends T> clazz);
// Return the list of MediaType objects supported by this converter.
List<MediaType> getSupportedMediaTypes();
// Read an object of the given type form the given input message, and returns it.
T read(Class<T> clazz, HttpInputMessage inputMessage) throws IOException,
;
// Write an given object to the given output message.
void write(T t, HttpOutputMessage outputMessage) throws IOException,
;
}
Spring MVC對HttpMessageConverter有多種默認實現，基本上不需要自己再自定義HttpMessageConverter
StringHttpMessageConverter - converts strings
FormHttpMessageConverter - converts form data to/from a MultiValueMap<String, String>
ByteArrayMessageConverter - converts byte arrays
SourceHttpMessageConverter - convert to/from a javax.xml.transform.Source
- convert to/from RSS feeds
- convert to/from JSON using Jackson's ObjectMapper
etc...
然而對於RESTful應用，用的最多的當然是。
但是不是默認的HttpMessageConverter：
public class extends WebContentGenerator
implements HandlerAdapter, Ordered, BeanFactoryAware {
...
public () {
// no restriction of HTTP methods by default
super(false);
// See SPR-7316
StringHttpMessageConverter stringHttpMessageConverter = new StringHttpMessageConverter();
stringHttpMessageConverter.setWriteAcceptCharset(false);
this.messageConverters = new HttpMessageConverter[]{new ByteArrayHttpMessageConverter(), stringHttpMessageConverter,
new SourceHttpMessageConverter(), new ()};
}
}
如上：默認的HttpMessageConverter是ByteArrayHttpMessageConverter、stringHttpMessageConverter、SourceHttpMessageConverter和轉換器。所以需要配置一下：
<bean class="org.springframework.web.servlet.mvc.annotation.">
<property name="messageConverters">
<list>
<bean class="org.springframework.http.converter.StringHttpMessageConverter">
<property name="supportedMediaTypes">
<list>
<value>text/plain;charset=GBK</value>
</list>
</property>
</bean>
<bean class="org.springframework.http.converter.json." />
</list>
</property>
</bean>
配置好了之後，就可以享受@Requestbody和@ResponseBody對JONS轉換的便利之處了：
@RequestMapping(value = "api", method = RequestMethod.POST)
@ResponseBody
public boolean addApi(@RequestBody
Api api, @RequestParam(value = "afterApiId", required = false)
Integer afterApiId) {
Integer id = apiMetadataService.addApi(api);
return id > 0;
}
@RequestMapping(value = "api/{apiId}", method = RequestMethod.GET)
@ResponseBody
public Api getApi(@PathVariable("apiId")
int apiId) {
return apiMetadataService.getApi(apiId, Version.primary);
}
一般情況下我們是不需要自定義HttpMessageConverter，不過對於Restful應用，有時候我們需要返回jsonp數據：
package me.arganzheng.study.springmvc.util;
import java.io.IOException;
import java.io.PrintStream;
import org.codehaus.jackson.map.ObjectMapper;
import org.codehaus.jackson.map.annotate.JsonSerialize.Inclusion;
import org.springframework.http.HttpOutputMessage;
import org.springframework.http.converter.;
import org.springframework.http.converter.json.;
import org.springframework.web.context.request.RequestAttributes;
import org.springframework.web.context.request.RequestContextHolder;
import org.springframework.web.context.request.ServletRequestAttributes;
public class extends {
public () {
ObjectMapper objectMapper = new ObjectMapper();
objectMapper.setSerializationConfig(objectMapper.getSerializationConfig().withSerializationInclusion(Inclusion.NON_NULL));
setObjectMapper(objectMapper);
}
@Override
protected void writeInternal(Object o, HttpOutputMessage outputMessage) throws IOException, {
String jsonpCallback = null;
RequestAttributes reqAttrs = RequestContextHolder.currentRequestAttributes();
if(reqAttrs instanceof ServletRequestAttributes){
jsonpCallback = ((ServletRequestAttributes)reqAttrs).getRequest().getParameter("jsonpCallback");
}
if(jsonpCallback != null){
new PrintStream(outputMessage.getBody()).print(jsonpCallback + "(");
}
super.writeInternal(o, outputMessage);
if(jsonpCallback != null){
new PrintStream(outputMessage.getBody()).println(");");
}
}
}