QGIS has a plugin that supports WPS 1.0.0. Just search for "WPS" in the plugin installer.
Open the plugin install, click on the Repositories, click Add 3rd party repositories and then click back on the Plugins tab.
Note: I can't tell you much about it as I have never had a use case for it.
Your question is rather broad, but from what you say, the best format would be GeoJSON. OpenLayers, Leaflet and Google Maps all read and display GeoJSON, with a trivial amount of coding required. Here is the Open Layers 3 GeoJSON example. OpenLayers 2 and 3 also have (Geo)JSON writers, which allow you to serialize OpenLayers vector objects back to JSON for database storage.
As far as getting JSON from the server in the first place is concerned, you have a couple of options from GeoServer.
WFS. This allows reading and updating of data and will transmit data in a number of formats, including GeoJSON. See the GeoServer WFS docs for more information. Here is the OpenLayers 3 WFS example
WPS. This allows you to send remote queries to GeoServer and get the results back in your web client, the default being JSON, see the Geoserver docs. Here is an OpenLayers 2 WPS example. This approach actually allows you to do GIS/spatial operations on your geometries, buffer, union, etc, remotely and get the results back in the client.
There are other options too, such as rolling your own, which you will have to do if you are just using AJAX to make the request -- you will have to then code up the server side somehow. To get multiple features our of Postgres, along with their attributes, you need to create a FeatureCollection. This can be done using the JSON datatype and the row_to_json and array_to_json functions. A typical query, which comes from Regina Obe, author of Postgis in Action, on the Boston Gis website looks like this:
SELECT row_to_json(fc)
FROM ( SELECT 'FeatureCollection' As type, array_to_json(array_agg(f)) As Features
FROM (SELECT 'Feature' As type,
ST_AsGeoJSON(lg.geog)::json As geometry,
row_to_json((SELECT l FROM (SELECT loc_id, loc_name) As l)
) As properties
FROM locations As lg )
As f )
As fc;
which is quite hard to look at when you first see it, but very powerful. This means you still have your geometries in a geometry field, so can do all the GIS analysis you want with, but still easily produce GeoJSON for display purposes.
There are also options using GeoDjango and the vectorformats library which will also produce GeoJSON with attributes directly from a Postgres table. You didn't specifically mention Python/Django, but as Python is so popular among GIS people, I thought this worth mentioning. Here is a longer blog article about the GeoDjango to GeoJSON approach.
Finally, it is not strictly true that you can not do analysis on JSON once it is in Postgres. Since Postgres 9.2 there has been a JSON datatype and in the upcoming Postgres 9.4 there will be a binary JSON format, known as JSONB which will allow indexing and search directly on JSON. I am not necessarily recommending this, given the rich array of functions available on separate geometry columns, but I mention if for completeness. I believe this is in some ways a response to the growing popularity of key/value stores in NoSQL databases, such as MongoDB, and will in no way displace Postgis's geometry column for GIS type queries.
There is also the WKT format, that can be used in a similar fashion, but it is much more of a pain to add attributes to it, and there is GML/XML, which allows for the encoding of complex structures, but is a pain to work with in Javascript (many would say, in general), whereas JSON is native, so perfect for "WebGIS".
Sorry, for such a long answer, but your question is rather broad :D
Best Answer
WPS is a stateless technology - you give it a process to execute (by HTTP GET or POST), and after some time, it gives you some sort of result. This may be a bit of XML or JSON, a link to an image, or the image itself.
On the server side, someone will have written one or more processes, detailing the expected inputs and the given outputs. The language these are written in are transparent to you the user. In the case of pyWPS they'll be written in Python. With the ZOO-project, it can be in one of a multitude of languages. But each process is completely standalone from any other process. Also, there is no standard set of processes that have to be created - so you are entirely at the whim of the WPS server you are connected to.
So the upshot is, the general way you as a user interact with a WPS is to chain processes together, and issue them in sequence via some sort of script. This could be some Javascript that makes successive execute requests, or a workflow system such as Taverna (see here for pyWPS working with Taverna). This is better than having monolithic processes on the server side because you keep nice small independent processes than can be chained in multiple ways rather than having to provide lots of parameters to control a process - and that's assuming you have access to the server in the first place. In addition, you could spread WPS servers over multiple machines, each one dedicated to a subset of processes which reduces server load, and provides possible parallelisation.