Updated wiki documentation.

doc/add_to_existing_app.md

@@ -14,22 +14,6 @@ There are a couple Spring MVC resources that Spring Data REST depends on that mu
 
 The most important things that we configure especially for use by Spring Data REST include:
 
-#### View Resolvers
-
-We register a `ContentNegotiatingViewResolver` that will order itself in the highest priority, which means it will attempt to override any other `ViewResolver`s you already have configured. Currently there are two views registered with this view resolver: a special `JsonView` and a `UrilistView` (for rendering `text/uri-list` resources which are used for links as an alternative to JSON). These views will only respond to special view names returned by the `RepositoryRestController`. These view names begin with "org.springframework.data.rest" as follows:
-
- * `org.springframework.data.rest.list_links` - For listing repositories registered and exported.
- * `org.springframework.data.rest.list_entities` - List entities (not a query but uses the `findAll` Repository method).
- * `org.springframework.data.rest.list_queries` - List query methods found and exported on a Repository.
- * `org.springframework.data.rest.query_results` - Results of calling a query method.
- * `org.springframework.data.rest.after_create` - Used after an entity is created.
- * `org.springframework.data.rest.empty` - Used whenever an empty response is sent back.
- * `org.springframework.data.rest.entity` - Renders an entity.
- * `org.springframework.data.rest.entity_property` - Renders the property of an entity.
- * `org.springframework.data.rest.linked_entity` - Renders a linked property of an entity.
-
-To register your own custom view for any of these internal view names, you need to subclass `RepositoryRestMvcConfiguration.contentNegotiatingViewResolver()` and mimic the functionality you find [in the source code](https://github.com/SpringSource/spring-data-rest/blob/master/spring-data-rest-webmvc/src/main/java/org/springframework/data/rest/webmvc/RepositoryRestMvcConfiguration.java#L59). You do not need to completely override all these views. You simply register custom views on the `RepositoryRestViewResolver` for either the JSON or uri-list views by setting the `customViewMappings` property with a `Map<String, View>` that overrides one or more of the above default views.
-
 #### RepositoryRestHandlerMapping
 
 We register a custom `HandlerMapping` instance that responds only to the `RepositoryRestController` and only if a path is meant to be handled by Spring Data REST. In order to keep paths that are meant to be handled by your application separate from those handled by Spring Data REST, this custom HandlerMapping inspects the URL path and checks to see if a Repository has been exported under that name. If it has, it allows the request to be handled by Spring Data REST. If there is no Repository exported under that name, it returns `null`, which just means "let other HandlerMapping instances try to service this request".

doc/configuring_path.md

@@ -128,3 +128,21 @@ Or to skip exporting a field:
       private Map<String, Profile> profiles;
     }
 
+### Hiding Repository CRUD methods
+
+If you don't want to expose a save or delete method on your `CrudRepository`, you can use the `@RestResource(exported = false)` setting by overriding the method you want to turn off and placing the annotation on the overriden version. For example, to prevent HTTP users from invoking the delete methods of `CrudRepository`, override all of them and add the annotation to the overriden methods.
+
+    @RestResource(path = "people", rel = "people")
+    public interface PersonRepository extends CrudRepository<Person, Long> {
+
+			@Override
+			@RestResource(exported = false)
+			void delete(Long id);
+
+			@Override
+			@RestResource(exported = false)
+			void delete(Person entity);
+
+    }
+
+NOTE: It is important that you override _both_ delete methods as the exporter currently uses a somewhat naive algorithm for determing which CRUD method to use in the interest of faster runtime performance. It's not currently possible to turn off the version of delete which takes an ID but leave exported the version that takes an entity instance. For the time being, you can either export the delete methods or not. If you want turn them off, then just keep in mind you have to annotate both versions with `exported = false`.

doc/jsonp.md

@@ -0,0 +1,50 @@
+# JSONP Support in Spring Data REST
+
+Spring Data REST supports [JSONP](http://en.wikipedia.org/wiki/JSONP) for doing safe cross-domain Ajax. JSONP support is integrated into the exporter so all you need to do to take advantage of it is pass the appropriate URL parameter. The default parameter is `callback`. So to get query method results wrapped with a call to your Javascript function, add `?callback=my_jsonp_callback` to the URL:
+
+ 		curl -v http://localhost:8080/people/search/findByName?name=John+Doe&callback=my_json_callback
+
+Which will result in:
+
+		HTTP/1.1 200 OK
+		Content-Type: application/javascript
+		Content-Length: ...
+
+		my_jsonp_callback({
+			"results": [ ... ],
+			"_links": [ ... ]
+		})
+
+### Configuring the URL parameter
+
+To configure what URL parameter is used, set the `jsonpParamName` property on your `org.springframework.data.rest.webmvc.RepositoryRestConfiguration` bean definition. In JavaConfig this would look like:
+
+		@Bean public RepositoryRestConfiguration restConfig() {
+			return new RepositoryRestConfiguration().
+				setJsonpParamName("jsonp");
+		}
+
+This would mean the above URL would become:
+
+ 		curl -v http://localhost:8080/people/search/findByName?name=John+Doe&jsonp=my_json_callback
+
+## JSONP-E Handling Errors
+
+It's usually not possible to easily handle server errors with JSONP. This is because many JSONP frameworks use a script tag insertion to perform cross-domain Ajax. If the JSONP request results in an HTTP 400 Bad Request, for example, no javascript will be evaluated because the page is considered in error.
+
+To deftly handle server errors using JSONP, you need to set a value on the `jsonpOnErrParamName` REST exporter configuration property (which is defaulted to `null`, which means don't handle errors). If this value is set, the exception handling code will look for a URL query string parameter of that name and use that javascript function to call as the error handler. The way it does this is by changing the HTTP status code from, for example 400, to 200 (OK). It then wraps the error message with a call to your javascript function and sends the original HTTP status code as the first parameter.
+
+For example, if a call to POST a new entity results in a validation error, the server will return a 400 Bad Request. If the `jsonpOnErrParamName` is specified and you send that URL parameter, it will instead return a 200 and call your javascript function. Assuming I have `jsonpOnErrParamName` set to "errback", I would trigger this error handling like this:
+
+		curl -v -d '...bad json data...' http://localhost:8080/people?errback=my_jsonp_error_handler
+
+Which would result in:
+
+		HTTP/1.1 200 OK
+		Content-Type: application/javascript
+		Content-Length: ...
+
+		my_jsonp_error_handler(400, {
+			"message": "Validation failed on property 'name'!",
+			"cause": { ... }
+		})