Tag Info

Hot answers tagged

11

The API being designed follows the Rest style of resources-centric URI and CRUD operations mapped to HTTP verbs. This is your problem right here. You have limited your resources to (I'm assuming) the models in your database. As such it is taking ages to load all these resources because your server has no concept of resources that don't have a ...


5

The statelessness of REST refers to the side of the server. If you pass around your token in every request this becomes part of the state that is being sent from the client and therefore does not violate the statelessness of your server. This differs from, for example, managing state on the server where you keep information in the session server-side. A ...


4

The technique your boss has told you to use is one of the common ways of preventing cross site request forgery. I think you're probably getting confused by the multiple meanings of "hash" which in this case probably refers to a secure hash (eg SHA256) rather than a hash that you might use for a hash table.


4

When creating a REST interface, there is no requirement, or even expectation, that the responses on the REST interface correspond directly to tables or joins in the database. Your /streams interface can just as easily be represented as [ { "listen_count" : 5, "user" : { "href" : "/users/10", "name" : "bla", }, "song" : ...


3

This is a classic API design dilemma, regardless of whether it's provided by a web service, or by linking a library, or by just being part of a code base that gets built along with everything else. It boils down to whether you prefer many functions that each do one specific thing, or whether you have fewer, more parameterized functions. Since web calls are ...


3

REST services are typically focused on resources, with the path separator (forward slash) denoting sub-resources in a hierarchy. Resources are typically things ("nouns" in English) rather than actions ("verbs" in English). To conform to this style, your "suggest" endpoint (a verb) could be named "suggestions" (a noun) because it provides access to ...


2

If your data is only meant to be persisted in Amazon S3 it's not performant to proxy it through your web server and should be avoided if possible. What you can do is create a POST policy that contains constraints on what the uploader (your Android app can do). You might create the following policy: Can only upload to specific bucket Specify min/max size ...


2

You definitely want a single GET operation that returns metadata about each song and user in addition to their opaque ids. As you pointed out, it's much simpler. That is a good thing. Making one of the most common operations for your client apps a single server request instead of O(n) requests is much more scalable. In the long run, the network will be ...


2

There is couple of comments that I would suggest you. You name your resource using verb instead of nouns. suggest is not really a good resource name. It give the client the idea that you are building a controller action and REST does not like it. suggestions is a better name. Now you can view it as a resource set of suggestions which is more RESTful. ...


2

In the first place it seems to be right, but I think you want to hide these implementation details. Ask your self: where is the difference between a local database and some remote data servers? You probably want to have a been for each resource like User and a store like UserStore. Each store has some methods for interaction like: public User ...


1

First of all, don't put REST above solving problems efficiently. In order for clients to be able to log in you need to somehow store some state. Whether or not you consider this to be against the REST mantra doesn't really matter, you need to do it anyway. You could make digitally signed tokens containing all session information, and not store those on the ...


1

I suggest that you 1) learn what other REST APIs do, and 2) consider OData I love Odata because it supports every scenario you listed in one single API call. I'm biased though, because in C# you can implement an Odata server in just a few lines of code if you use the Entity Framework. There's also client side libraries that can format OData URLs. Let me ...


1

I have done such things as REST, which, as you say, doesn't solve all problems, though at least a few of them possibly. Basically search features I have implemented using URL params instead having a single URL for each of them. So your get_user_by_email would just be /user?email=joe.doe@something.net Similar you can handle the returned data for things ...


1

Regarding the table, if a book can have many labels and a label many books (sounds quite reasonable) then that's a many to many relationship. In case of REST the many to many relation is in fact a bit confusing since we talk about resources and with the URI being a unique identifier it seems weird to be able to access one and the same resource from two ...



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