Tag Info

Hot answers tagged

4

You are supposed to couple the Uniform Resource Identifier to the resource. When REST is implemented with HTTP, you use GET to retrieve the current value of the resource and PUT to set a new value. The GET does not have a payload, so the resource has to be identified by the URI. And the PUT is logically done to the same URI and the payload should look ...


2

One of the principles in REST is that you have one URL to retrieve a particular resource through. For "Customer 23", this URL is /Customer/23. If you start returning the Customer resource also from /Customer/23/Orders, you suddenly have two URLs to retrieve that Customer resource, with the associated questions what the difference is between those two ...


2

HATEOAS is a somewhat controversial topic. Many people feel it's an example of overengineering and see no practical benefit to it. I believe it offers a natural and sensible approach to implementing Web APIs, with the benefits of increased decoupling between server and clients and a lower burden on client developers (see my answer to "REST HATEOAS - How does ...


2

Then just don't make a public API. Make your web server build the HTML in the back-end and simply return it as a whole. KISS. If you want to build a HTML/JS front-end that calls public JSON/whatever REST services, there will be hundreds of ways to call the services directly┬╣, even it means to simulate a browser (which is really not as hard as it sounds). ...


2

expose the existing complex data model without introducing DTO classes One major flaw of this approach is that of coupling data access layer with API. It can go very bad very quickly if those models are used elsewhere except API. I currently work on a project where both web interface and JSON API (kind of REST, but not quite) use the same Hibernate ...


1

That's, what links are for: E.g. requesting the first post via GET http://example.com/posts/1 { "id": "1", "author": { "nickname": "me" }, "links": [ { "rel": "self", "href": "http://example.com/posts/1" }, { "rel": "author", "href": ...


1

You could do something similar to what discogs do in their API, http://www.discogs.com/developers/#page:database,header:database-release. When requesting a release /releases/{release_id} the response also includes a subset of artist data, extract from the response body: { "title": "Never Gonna Give You Up", "id": 249504, "artists": [ ...


1

Independent from implementing a key-value-store or whatever: you could use HATEOAS to describe your api. This enrichens the plain ressource information with meta-information what to do with your API. So in your example a call to base gives a collection of keys and their values: GET /baseurl/ gives you a resultset: [ { "links": { ...


1

Second approach is a bad/inferior idea. You lose the ability to cache individual resources using standard caching methods (both on the server and client). You lose the ability to sync individual resource state using HTTP headers and timestamps You lose the ability to update resources as you go (why wait to push a change to the server, just push it when ...


1

In REST, you should think of URIs as identifying an addressable resource. So as long as you think of a "sync" as a noun ;) you can define that resource in whatever manner suits your requirements. At surface level, in REST we talk about collection resources (like the collection of users) and individual resources (like a single user), so a resource that is an ...



Only top voted, non community-wiki answers of a minimum length are eligible