Today we’re excited to announce that rest.js is now part of Cujo.js and that rest.js 0.9 has been released.

https://github.com/cujojs/rest

rest.js is a RESTful HTTP client. It goes far beyond the typical XMLHttpRequest abstraction developers are accustomed to in other frameworks. rest.js is built upon composable interceptors that incrementally add new functionality to a client. Configured clients are tamper proof and can be safely shared within an application. If a portion of the application needs specific behavior, it can chain further interceptors on the common…

We are pleased to announce the release of when.js 2.0.0.

When.js is cujojs’s lightweight Promises/A+ and when() implementation, and powers the async core of wire.js, cujojs’s IOC Container. It also provides several other useful Promise-related concepts, such as joining multiple promises, mapping and reducing collections of promises, and timed promises.

This major release brings full Promises/A+ compliance, and async promise resolutions. It also includes a few new features, including a new when/keys module for working with object keys.

See the cujojs discussion group for further detail, and check out the full changelog for more info and direct links to docs for the new features.

we are happy to announce the next major release of our Eclipse-based tooling today: The Spring Tool Suite (STS) 3.2.0 and the Groovy/Grails Tool Suite (GGTS) 3.2.0.

Highlights from this release include:

• Eclipse Juno SR2 updates (including Mylyn, EGit, m2e, m2e-wtp)
• added support for high-res displays on Mac OSX
• updated bundled tc Server to 2.8.2
• major performance improvements for working with Spring projects
• major improvements to the Live Spring Beans Graph
• added support for Spring Integration 2.2
• updated to include Groovy 2.0.7 and Grails 2.2.1 (Groovy 2.1 is available from the dashboard)

We continue to ship distributions both on top of Eclipse 3.8 and Eclipse 4.2. While the 4.2 stream of Eclipse has improved a lot in the Eclipse Juno SR2 release, we still recommend using the 3.8-based version for optimal performance and stability.

To download the distributions, please go visit:

• Spring Tool Suite: http://www.springsource.org/sts
• Groovy/Grails Tool Suite: http://grails.org/products/ggts

Updates from STS/GGTS 3.0.0 and 3.1.0 are available through the automatic…

Spring Data REST Home | Source on GitHub | Reference Documentation

Export domain objects to the web

Spring Data REST is a set of Spring MVC components that you can add to your own Spring MVC applications that export your Spring Data Repositories to the web using RESTful, HATEOAS semantics. It provides a consistent interaction API by exporting repositories to RESTful URLs that are configurable in a couple different ways.

Spring Data REST supports CRUD for top-level entities (those domain objects directly managed by a Spring Data Repository) by literally writing a single line of code that defines an interface that extends Spring Data's CrudRepository interface. That done, your entities then have full RESTful semantics. You can create new ones, update existing ones, and delete them using standard URLs that are, following the principles of HATEOAS, discoverable. That means the user agent accessing your Spring Data REST application doesn't need to have advance knowledge of what resources you are exporting. It can discover what entites exist and what relationships exist on those entities by successive calls to URLs provided in the JSON. These "links" are the real foundation and power of a HATEOAS REST application.

Changes from the ground up

Version 1.1 is virtually a re-write from the ground up. Not only is it easier to configure than 1.0 and better conforms to Spring MVC expections for the transition to Spring 3.2, but the biggest change in the internals of Spring Data REST is that it now supports other types of Spring Data repository implementations beyond just JPA. The HTTP semantics for CRUD and manging relationships (if the datastore supports it) remain the same no matter what backing datastore is used.

That means it's now possible to export JPA entities and MongoDB entities within the same Spring Data REST application and access those entities using a common URL structure and using the standard Spring HATEOAS Resource representation for all entities and collections. The user agent accessing those RESTful URLs does not need any special knowledge on which datastore the backing entities are managed by and, most importantly, you don't have to write any code to get that functionality!

MongoDB support

Spring Data REST 1.1 now supports exporting MongoDB CrudRepository implementations. The same HTTP semantics apply to MongoDB @Document entities as apply to JPA entities. GET, POST, PUT, DELETE are of course supported, but so is @DBRef. You can view and manage the relationship between two documents using GET, POST, PUT, and DELETE and you can export finder methods based on your @Query definitions. Please reference the spring-data-mongodb reference documentation for the full details of how the object mapping differs from JPA style mapping and how query definitions work.

Gemfire support

Spring Data REST 1.1 now supports exporting entities that use the high-performance Gemfire database to different Regions. Read the Spring Data Gemfire documentation for the full explanation of the vast configuration options and how POJO mapping in Gemfire differs from other mapping technologies.

Neo4J support is next

Spring Data REST 1.1 is now set to support Neo4J GraphRepositorys with the next version of spring-data-neo4j, version 2.3. When that's generally available (which should be around or before the general availablity of Spring Data REST 1.1 RELEASE), you will be able to access @NodeEntitys and their relationships using standard HATEOAS semantics, just like you do with the other datastores.

Add it to your existing apps

Spring Data REST is designed in such a way that you can, if you wish, create an entire application for the Spring Data REST application. It's just a standard Spring MVC webapp after all. But things get really interesting when you add Spring Data REST to your own services.

Spring HATEOAS author Oliver Gierke has created an example application that demonstrates the use of HATEOAS principles in a modern web application. It's called spring-restbucks and is an implementation of the Restbucks application described in the Systematic Theology of REST services: REST in Practice by Jim Webber, Savas Parastatidis and Ian Robinson.

Mixin REST services

By mixing Spring Data REST with your other RESTful services, you can get a seamless integration between those domain objects exported by Spring Data REST--objects for which you didn't have to write any code to have them exposed--and those services that don't represent an actual entity but a process. You can see an example of how a payment service might interact with domain object CRUD in the spring-restbucks application, where credit card payment processing is handled by a custom controller, while object CRUD is handled by Spring Data REST. Your custom controllers can actually piggyback onto the Spring Data REST URLs so that a consistent and simple URL structure can be maintained throughout the appliation, no matter whether the URL refers to your custom controller, a Spring Data REST JPA Repository, or any of the other supported Repository styles.

It's not exclusive

It's not an either-or with Spring Data REST. If you don't want all of your Repositories exposed to a web client, no problem! There a several different ways you can turn off functionality for Repositories. You can embed annotations into your source code or, if you don't have access or simply can't add the Spring Data REST annotations, you can use a fluent, DSL-style configuration to tell Spring Data REST how your resources should be exposed. Using Spring Data REST in your application isn't an exclusive committment to only one way of doing things. Spring Data REST is structured in a what that it will play nicely with your existing application so you can incorporate those bits of functionality from Spring Data REST you want, while still maintaining all the custom-coded services you're used to creating in Spring MVC controllers.

JSONP support moving to a filter

The JSONP support that was built into Spring Data REST 1.0 has been removed from the core framework in preference to a forthcoming general-purpose JSONP Serlvet Filter that will work much better than the way JSONP was implemented in version 1.0. When that filter is generally available, then JSONP support can be added not just to Spring Data REST, but virtually any Servlet-based REST resource.

Installation and Documentation

To get started playing with Spring Data REST, have a look at the reference documentation to get the lay of the land, so to speak, and get started playing with it in your own application by simply adding a dependency to the spring-data-rest-webmvc artifact (currently at 1.1.0.M1 in the SpringSource milestone repository) then import the Spring Data REST configuration like you see being done in the spring-restbucks application.

Learn more at CONFESS_2013

If you're planning on attending CONFESS_2013 in Vienna the first week of April, then you can hear all about Spring Data REST at my talk on exporting entities to the web.

Links

Spring Data REST Home | Source on GitHub | Reference Documentation

Site | Download | Reference | Javadoc

This is a minor release containing a few important bug fixes.

The release notes can be found here.

The project page is here.

This is a minor maintenance release with fixes to a few minor issues in the AMQP Log4j Appender, as well as correcting an issue in the spring-rabbit manifest for OSGI users.

Release notes can be found here.

The project home page is here, where you can find links to documentation, downloads and APIs.

We are happy to see more community contributors and are continuing our efforts to promote that growing trend, both in the core project and the extensions respository.

• Release notes are available here.
• Reference Documentation is here.
• Artifacts are available in the SpringSource Milestone repo and the community download page.

More information is available on the project's home page.

We are pleased to announce the release of when.js 1.8.0.

When.js is cujojs’s lightweight Promises/A and when() implementation, derived from the async core of wire.js, cujojs’s IOC Container. It also provides several other useful Promise-related concepts, such as joining multiple promises, mapping and reducing collections of promises, and timed promises.

Among other things, this release includes an extensive set of adapters for working with existing callback-based APIs, including node-style async APIs, allowing you to effectively convert them into promise-aware functions. In addition, most of the new features in this release are community contributions, which is awesome. Keep it coming!

Some specific highlights include:

• Adapters for promisifying existing callback-based code.
• Mechanisms for generating and processing unbounded/infinite lists
• Promise-based periodic polling utility.

Check out the changelog for more info and direct links to docs for all the new goodies.

If you're still wondering what this cujojs thing is all about, be sure to check out Brian Cavalier and John Hann's "IOC + JavaScript" talk from SpringOne 2012.