這是有關使用Spring 3.1和Spring Security 3.1和基于Java的配置來建立安全的RESTful Web Service的系列文章的第五篇。 上一篇文章介紹了RESTful服務HATEOAS的可發現性的概念，然后介紹了一些由測試驅動的實際方案。 本文將重點介紹可發現性的實際實現以及使用Spring 3.1在REST服務中滿足HATEOAS約束的情況。

通過事件使可發現性脫鉤

可發現性作為Web層的一個單獨方面或關注點 ，應與處理HTTP請求的控制器分離。 為此，Controller將觸發所有需要對HTTP響應進行其他操作的操作的事件：

@RequestMapping( value = "admin/foo/{id}",method = RequestMethod.GET ) @ResponseBody public Foo get( @PathVariable( "id" ) Long id, HttpServletRequest request, HttpServletResponse response ){Foo resourceById = RestPreconditions.checkNotNull( this.service.getById( id ) );this.eventPublisher.publishEvent( new SingleResourceRetrieved( this, request, response ) );return resourceById; } @RequestMapping( value = "admin/foo",method = RequestMethod.POST ) @ResponseStatus( HttpStatus.CREATED ) public void create( @RequestBody Foo resource, HttpServletRequest request, HttpServletResponse response ){RestPreconditions.checkNotNullFromRequest( resource );Long idOfCreatedResource = this.service.create( resource );this.eventPublisher.publishEvent( new ResourceCreated( this, request, response, idOfCreatedResource ) ); }

然后，可以通過任意數量的解耦偵聽器來處理這些事件，每個偵聽器都專注于其自身的特定情況，并且每個都在努力滿足總體HATEOAS約束。

同樣，偵聽器應該是調用堆棧中的最后一個對象，并且不需要直接訪問它們。 因此，它們不是公開的。

使新創建資源的URI可被發現

如前一篇文章所述，創建新資源的操作應在響應的Location HTTP標頭中返回該資源的URI。 ：

@Component class ResourceCreatedDiscoverabilityListener implements ApplicationListener< ResourceCreated >{@Overridepublic void onApplicationEvent( ResourceCreated resourceCreatedEvent ){Preconditions.checkNotNull( resourceCreatedEvent );HttpServletRequest request = resourceCreatedEvent.getRequest();HttpServletResponse response = resourceCreatedEvent.getResponse();long idOfNewResource = resourceCreatedEvent.getIdOfNewResource();this.addLinkHeaderOnResourceCreation( request, response, idOfNewResource );}void addLinkHeaderOnResourceCreation( HttpServletRequest request, HttpServletResponse response, long idOfNewResource ){String requestUrl = request.getRequestURL().toString();URI uri = new UriTemplate( "{requestUrl}/{idOfNewResource}" ).expand( requestUrl, idOfNewResource );response.setHeader( HttpHeaders.LOCATION, uri.toASCIIString() );} }

不幸的是，即使在Spring 3.1中，處理低級別的請求和響應對象也是不可避免的，因為仍在努力提供用于指定Location的一流支持。

獲取單一資源

檢索單個資源應允許客戶端發現URI以獲取該特定類型的所有資源：

@Component class SingleResourceRetrievedDiscoverabilityListener implements ApplicationListener< SingleResourceRetrieved >{@Overridepublic void onApplicationEvent( SingleResourceRetrieved resourceRetrievedEvent ){Preconditions.checkNotNull( resourceRetrievedEvent );HttpServletRequest request = resourceRetrievedEvent.getRequest();HttpServletResponse response = resourceRetrievedEvent.getResponse();this.addLinkHeaderOnSingleResourceRetrieval( request, response );}void addLinkHeaderOnSingleResourceRetrieval( HttpServletRequest request, HttpServletResponse response ){StringBuffer requestURL = request.getRequestURL();int positionOfLastSlash = requestURL.lastIndexOf( "/" );String uriForResourceCreation = requestURL.substring( 0, positionOfLastSlash );String linkHeaderValue = RESTURLUtil.createLinkHeader( uriForResourceCreation, "collection" );response.addHeader( LINK_HEADER, linkHeaderValue );} }

請注意，鏈接關系的語義使用了“ 集合 ”關系類型，該類型以多種微格式指定和使用，但尚未標準化。

出于可發現性的目的， Link頭是最常用的HTTP頭之一。 因此，需要一些簡單的實用程序來簡化在服務器上創建其值并避免引入第三方庫的情況。

從根本上發現

根是RESTful Web服務中的入口點–它是客戶端首次使用API??時與之聯系的對象。 如果要始終考慮并實施HATEOAS約束，那么這是一個起點。 到目前為止，必須從根目錄中發現系統的大多數主要URI，這一事實不足為奇。

這是從根本上提供可發現性的示例控制器方法：

@RequestMapping( value = "admin",method = RequestMethod.GET ) @ResponseStatus( value = HttpStatus.NO_CONTENT ) public void adminRoot( HttpServletRequest request, final response ){String rootUri = request.getRequestURL().toString();URI fooUri = new UriTemplate( "{rootUri}/{resource}" ).expand( rootUri, "foo" );String linkToFoo = RESTURIUtil.createLinkHeader( fooUri.toASCIIString(), REL_COLLECTION );response.addHeader( HttpConstants.LINK_HEADER, linkToFoo ); }

當然，這是該概念的說明，可以在該系列的概念證明RESTful服務的上下文中閱讀。 在更復雜的系統中，會有更多的鏈接，每個鏈接都有自己的語義，這些語義由鏈接關系的類型定義。

可發現性與更改URI無關

與可發現性相關的最常見陷阱之一是一種誤解，因為現在可以發現URI，因此它們可能會發生變化 。 但是，事實并非如此，這是有充分理由的：首先，這不是Web的工作方式–客戶將URI加為書簽，并希望它們將來能夠正常工作。 其次，客戶端不必瀏覽API就可以直接到達某個狀態。

取而代之的是，RESTful Web服務的所有URI都應被視為即興URI ，而URI 不變 。 相反，可以使用API??的版本控制來解決URI重組的問題。

可發現性警告

正如前幾篇文章中的某些討論所指出的那樣，可發現性的首要目標是最大限度地減少文檔使用或不使用文檔，并讓客戶通過獲得的響應來學習和理解如何使用API??。 實際上，這不應該被視為遙不可及的理想-這是我們如何使用每個新網頁- 無需任何文檔 。 因此，如果該概念在REST上下文中存在更多問題，那么它必須是技術實施的問題，而不是是否可能的問題。

話雖這么說，從技術上講，我們離一個完整的解決方案還差得很遠–規范和框架支持仍在不斷發展，因此，可能必須做出一些折衷。 然而，這些都是妥協，應視為妥協。

結論

本文介紹了在具有Spring MVC的RESTful服務的上下文中實現可發現性的某些特征，并從根本上涉及了可發現性的概念。 在接下來的文章中，我將重點介紹自定義鏈接關系和Atom發布協議。 同時，檢查github項目 。

參考： Baeldung博客上我們JCG合作伙伴 Eugen Paraschiv的第5部分 ： Spring的REST服務發現性 。

相關文章 ：

• 使用Spring 3.1和基于Java的配置引導Web應用程序，第1部分
• 使用Spring 3.1和基于Java的配置構建RESTful Web服務，第2部分
• 使用Spring Security 3.1保護RESTful Web服務，第3部分
• RESTful Web服務可發現性，第4部分
• 使用Spring Security 3.1的RESTful服務進行基本身份驗證和摘要身份驗證，第6部分
• Spring＆Quartz集成自定義注釋
• Spring MVC攔截器示例
• 在運行時交換出Spring Bean配置

翻譯自: https://www.javacodegeeks.com/2011/12/rest-service-discoverability-with.html

總結

以上是生活随笔為你收集整理的Spring的REST服务发现性，第5部分的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。