Сравнение данных с УСПОКОИТЕЛЬНЫМ API

There is nothing in HTTP that says that POST must update the server. People seem to forget the following line in RFC2616 regarding one use of POST:

• Providing a block of data, such as the result of submitting a form, to a data-handling process;

There is nothing wrong with taking your client side wishlist and POSTing to a resource whose sole purpose is to return a set of differences.

POST /Bookstore/WishlistComparisonEngine

I think the key problems here are the definitions of Book and Wishlist, and where the authoritative copies of Wishlists are kept.

I'd attack the problem this way. First you have Books, which are keyed by ISBN number and have all the metadata describing the book (title, authors, description, publication date, pages, etc.) Then you have Wishlists, which are merely lists of ISBN numbers. You'll also have Customer and other resources.

You could name Book resources something like:

/book/{isbn}

and Wishlist resources:

/customer/{customer}/wishlist

assuming you have one wishlist per customer.

The authoritative Wishlists are on the server, and the client has a local cached copy. Likewise the authoritative Books are on the server, and the client has cached copies.

The Book representation could be, say, an XML document with the metadata. The Wishlist representation would be a list of Book resource names (and perhaps snippets of metadata). The Atom and RSS formats seem good fits for Wishlist representations.

So your client-server synchronization would go like this:

GET /customer/{customer}/wishlist
for ( each Book resource name /book/{isbn} in the wishlist )
    GET /book/{isbn}

This is fully RESTful, and lets the client later on do PUT (to update a Wishlist) and DELETE (to delete it).

This synchronization would be pretty efficient on a wired connection, but since you're on a mobile you need to be more careful. As @marshally points out, HTTP 1.1 has a lot of optimization features. Do read that HTTP caching tutorial, and be sure to have your web server properly set Expires headers, ETags, etc. Then make sure the client has an HTTP cache. If your app were browser-based, you could leverage the browser cache. If you're rolling your own app, and can't find a caching library to use, you can write a really basic HTTP 1.1 cache that stores the returned representations in a database or in the file system. The cache entries would be indexed by resource names, and hold the expiration dates, entity tag numbers, etc. This cache might take a couple days or a week or two to write, but it is a general solution to your synchronization problems.

You can also consider using GZIP compression on the responses, as this cuts down the sizes by maybe 60%. All major browsers and servers support it, and there are client libraries you can use if your programming language doesn't already (Java has GzipInputStream, for instance).

Вся концепция REST заключается в том, что вы используете мощь базового протокола HTTP.

В этом случае есть два заголовка HTTP, которые могут помочь вам определить, устарел ли список на вашем мобильном устройстве. Дополнительным преимуществом является то, что клиент на вашем мобильном устройстве, вероятно, изначально поддерживает эти заголовки, а это значит, что вам не придется добавлять какой-либо код на стороне клиента для их реализации!

If-Modified-Since : проверьте, есть ли копия сервера была обновлена ​​с тех пор, как ваш клиент впервые ее получил Etag: check to see if a unique identifier for your client's local copy matches that which is on the server. An easy way to generate the unique string required for ETags on your server is to just hash the service's text output using MD5.

You might try reading Mark Nottingham's excellent HTTP caching tutorial for information on how these headers work.

If you are using Rails 2.2 or greater, there is built in support for these headers.

Django 1.1 supports conditional view processing.

And this MIX video shows how to implement with ASP.Net MVC.

Третий вариант звучит неплохо, но я согласен, что он не подходит для RESTfull ...

Вот еще одно предложение, которое может сработать, а может и не сработать: если вы храните историю версий вашего списка, вы можете запросить обновления, начиная с определенной версии. Это больше похоже на операцию GET. Идентификаторы версии могут быть либо простыми номерами версий (например, в svn), либо, если вы хотите поддерживать ветвление или другую нелинейную историю, они могут быть своего рода контрольными суммами (например, в монотонном).

Отказ от ответственности: I ' Я ни в коем случае не являюсь экспертом в философии или реализации REST.

Edit: Вы объявили это PS после того, как я загрузил вопрос? Или я просто не прочитал ваш вопрос до конца, прежде чем написать ответ? Сожалею. Я все же думаю, что управление версиями может быть хорошей идеей.

If I strip out the domain-specific details from your question, here's what I get:

In your RESTful client-server application, the client stores a local copy of a large resource. Periodically, the client needs to check with the server to determine whether its copy of the resource is up-to-date.

marshally's suggestion is to use HTTP caching, which IMO is a good approach provided it can be done within your app's constraints (e.g., authentication system).

The downside is that if the resource is stale in any way, you'll be downloading the entire list, which sounds like it's not feasible in your situation.

Instead, how about re-evaluating the need to keep a local copy of the Wishlist in the first place:

• How is your client currently using the local Wishlist?
• If you had to, how would you replace the local copy with data fetched from the server?
• What have you done to minimize your client's data requirements when building its Wishlist view(s) and executing business logic?