Tag Info

New answers tagged

0

You may take some inspiration from the ODATA protocol as a variation to your option 1. It has so called query options one of which is $expand that takes the value of the related resource to return. The $expand system query option specifies the related resources to be included in line with retrieved resources. The request below returns people with navigation ...


0

You can also do it in one call by embedding authors inside posts. JSON Hypertext Application Language describes how to do this, see https://tools.ietf.org/html/draft-kelly-json-hal-06 e.g. (modified copy from the doc): { "_links": { "self": { "href": "/posts" }, "next": { "href": "/posts?page=2" }, "find": { "href": ...


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": ...


0

In general you have one endpoint which represents the whole collection of x: /products Say, you want to update a single product, you make a PUT to /products/{id}. If you want to partially update a single product (not updating every field), you could also use a PATCH to /products/{id}. The same goes for deletion of a single entity (DELETE to ...


0

Just to precise previous answers / comments. As per my knowledge, POST is the method to add single elements to the collection. DELETE in turn, is the method to delete single element from the collection. Both scenarios are perfectly RESTful. However, you should use appropriate URI to refer single element or the whole collection. For example, to add ...


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": [ ...


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 ...


0

Have a look at the guidelines from the Heroku team. Amongst other things such as Etags they suggest a Request-Id in the header. We are looking to implement most of these guidelines where they make sense. Trace requests with Request-Ids Include a Request-Id header in each API response, populated with a UUID value. If both the server and client log ...


0

Serving smaller and more numerous requests should not be so much of a risk to the server, unless you leave the synchronization as a user-triggered event. See, when you leave the synchronization to the user, it is always going to be heavy, regardless of whether the requests are small but many, or few but big, you're always at risk of having too much network ...


0

How much difference in application performance or server overhead is having one network call rather than two per update going to make? Well, it depends on how many simultaneous clients you expect, and how often they'll be polling for updates. If you have a "small number of clients" like 10 or 50, and they request updates every N seconds (say N between 10 and ...


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 ...


0

If you don't want your users to view the data in the format that is returned by the API to the client side JS, then you can do the client side processing/aggregation on the server itself and return the aggregated data via your API. This way the API will only return the data that the users are allowed to see and your JS framework works just as a presentation ...


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 ...


0

I started to use Django framework with python. It is really good technology. Both development and runtime speed is really fast. I mean, you can develop your server app very fast and also it is process performance is really good. Django Rest Framework is really good for RESTful services.


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 ...


0

When you say, a user has a house; and each house has adress data, that means in reverse: no address without a house - which makes by the way no sense. From that the procedure should be clear: Usecase: Creation of house 1) User enters all relevant data 2) A GET-Request is sent to a geocode-Service, which returns possible addresses 3) Only after the user ...


0

This answer expands on toniedzwiedz comments, so anyone else read them as well. So reading through the question it becomes clear that you do not trust the user's description of the address, but you DO trust the user's description of the geo-code id of the address. That is to say the user is not the authority of the address format for the house, the ...


0

Thinking about this some more, we are coupling the resource to the URI. If the URI doesn't have the ID, the payload will need to be amended: PUT /no/id/here Payload: {name: "Adrian"} < What user??? Are there any reasons not to? The answer to this question depends on whether you want to allow the client to change the ID? If the ...


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 ...



Top 50 recent answers are included