Tag Info

Hot answers tagged

25

I think your instincts are largely correct; those proclaimed benefits really aren't all that great, as for any non-trivial web application the clients are going to have to care about the semantics of what they're doing as well as the syntax. But that doesn't mean that you shouldn't make your application follow the principles of HATEOAS! What does HATEOAS ...


15

An API should be as consistent as possible. Making the same call to the API should always do the same thing. Responding differently based on the client version would be unexpected and confusing. It may lead to subtle errors, as someone who upgrades a client would get different results and not know why. Of course, you can make functions that provide ...


5

Almost without exception, no. Methods represent behaviors. Behaviors generally aren't supposed to change depending on who the consumer is. For example, when you walk into a restaurant, do you expect to get treated differently because of your gender or your skin color? Of course not. The implicit contract that every restaurant makes with the world is: ...


3

Since verbs in REST under HTTP are restricted to the HTTP verbs, everything in the URI should be name a noun. So the common trick is to do what you say -- convert the custom verb (sendemail) to a processor noun (emailsender) instead. At first that seems like a word trick, but it does have some merit. You can then use the "data processing" provision of the ...


2

The problem that you can run into without the idea of supporting client version is that it becomes very difficult to change your data representations required and sent by the API. Representation changes can force client applications to change and leave them in a broken state until they do. Not including a client version scheme makes sense if the API is ...


2

I have successfully used both patterns; and both will work fine. I wouldn't say that either is more complicated than the other. One thing that you might also consider, for the first pattern, is to include in your entity description a "promise" to fulfill. For example, you might have a JSON object that enumerates the data you'll be providing: ...


2

Remember you can use the query string to filter or limit the result. Since you're looking for a user's tokens, limited to a particular application, this is pretty natural GET /user/tokens?application=:id The resource is a collection of tokens, limited by an application ID. This is consistent with /user/tokens/:id except that you're narrowing the result ...


1

There is probably no consensus on solutions for such actions. Hey, from what I've read there's not even consensus on how to implement all required characteristics of a REST API. For performing different actions then just storing resources the resource based URLS can be used. For example sending mail could be implemented as a POST request of a message ...


1

So you're working with an old api and a class that calls that api, right? For the class that calls it, you can hide the string from the client of the class. In other words, if you can make it so that the user doesn't have to know the string and doesn't have to worry about spelling it correctly, that's better, in my opinion. And you're asking if that class ...


1

The things is, HATEOAS must come with a second pillar that define what a RESTful API is : standardized media type. Roy fielding himself said A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources". With a standardized media type that define the transition explicitely, and hypertext to ...


1

Although I agree with @dan1111 that a server has no business acting different according to the client version, I can see a case where you add a feature to one of the APIs and: You don't want to change its name/end-point/whatever just to differentiate it from the previous version, because you plan to deprecate the previous version, and don't want the API to ...


1

One approach to consider is treating the set of possible queries as a collection resource, e.g. /jobs/filters. POST requests to this resource, with the query parameters in the body, will either create a new resource or identify an existing equivalent filter and return a URL containing its ID: /jobs/filters/12345. The id can then be used in a GET request ...



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