Tag Info

New answers tagged

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

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


0

Spring is a very powerful framework. The convenience of Spring lies in the fact that incorporates several projects: in this way you can manage all your needs with a single framework. The development is simple and well supported by tutorials. I'm developing an application that manages a set of REST WS and no GUI. You mainly need Hibernate, SpringMVC and ...


0

Where did you read that "documentation is no longer needed" for HATEAOS services? As you say, you still need to document the semantics of the links. However, with HATEOAS you don't need to document, and hence keep forever, the structure of most of the URIs. HATEOAS allows a service implementer to modify and scale the implementation significantly and ...


23

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


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


0

First of all, let's give your resource a name: let's call it a publication. This is to disambiguate it from another kind of resource your design is implying: the translation. Second, let's agree to the fact that a collection of resources is also a resource itself. Having said that, a publication looks to me more like a collection of translations. Third, ...


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


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


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


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


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


0

TL;DR: Scheme 3 If you only ever support the individual "leaf" resources then it doesn't make much of a difference. If you consider extending functionality to GET'ting collections; then I think scheme 3 becomes the obvious choice. It creates a more usable hierarchy for querying. You can get all the relevant news for that user, or possibly filtered by any ...


0

TL;DR: Not mime types. Probably query parameters When writing REST APIs I usually have the underlying structure of my responses the same, regardless of mime type. The mime type is just the particular representation of the underlying structure. This allows for things like caching to not care what the mime type is because the data is the same. Using a ...


1

TL;DR: GET for filtering, POST for searching I make a distinction between filtering the results from listing a collection vs a complex search. The litmus test I use is basically if I need more than filtering (positive, negative, or range) I consider it a more complex search requiring POST. This tends to be reinforced when thinking about what will be ...


5

In REST, resource definition is very broad. It's really however you want to bundle some data. It's useful to think of a search resource as a collection resource. The query parameters, sometimes called the searchable portion of the URI, narrow the resource down to the items the client is interested in. For example, the main Google URI points to a ...


13

You should not forget that GET requests have some superior advantages over other solutions: 1) GET requests can be copied from the URL bar, they are digested by search engines, they are "friendly". Where "friendly" means that normally a GET request should not modify anything inside your application (idempotent). This is the standard case for a search. 2) ...


4

I generally use OData queries, they operate as a GET call but allow you to restrict the properties which are returned and filter them. You use tokens such as $select= and $filter= so you will end up with a URI which looks something like this: /users?$select=Id,Name$filter=endswith(Name, 'Smith') You can also do paging using $skip and $top and ordering. ...


1

Several reasonably successful implementations I have seen/built answer the question in how they mix the verb+noun metaphor using coarse-grained 'business friendly' methods that act on the entities. So instead of the (doomed) getName() method/service, expose getPerson(), passing in things like identifier-type/ID, returning the entire Person entity. Since ...



Top 50 recent answers are included