Tag Info

Hot answers tagged

6

I've had the same problem and "solved" it by modelling REST resources differently, e.g.: /users/1 (contains basic user attributes) /users/1/email /users/1/activation /users/1/address So I've basically split the larger, complex resource into several smaller ones. Each of these contain somewhat cohesive group of attributes of the original resource which ...


3

The problem is the URL is not RESTful in the GitHub example: I would rather see actual URL that represent the resource exclusively. It is not that hard if you put a little thought into it. To be truly RESTful the URI should be a resource identifier and nothing else Parameters make it RPC over HTTP which is the opposite of the REST paradigm. ...


3

This seems to me to be a straightforward case of the Granovetter introduction operator as applied by the client in a request - the resource receiving the request needs no prior knowledge of the specific external resource referenced (only that it have compatible behavior), and so long as the external resource being referenced is treated as a subject or object ...


3

I think that this is the perfect fit for Bounded Context pattern from Domain Driven Design. Large models don't scale well, it's better to split them into smaller models (bounded contexts) and explicitly declare their relationships (common entities, interactions between bounded contexts etc.) In this case you would have two bounded contexts (sales and ...


2

I've seen good APIs designed both ways. On the one hand, providing the userId in authentication and the URL seems redundant. On the other hand, it could be more consistent to have an explicit Id in the URL if there are also ways for one user to look at public data of another user or you are using the same or a similar API in clients that need to get data ...


1

A lot of questions of this kind depend heavily on the actual business domain, and it's not clear that we have enough information to make a good decision. any rebind is treated as non-normal situation This comment suggests that it may make the most sense to send back a error response (e.g. 400 Bad Request) with a description of the reason you're not ...


1

The scenario you describe assumes that when the software is re-installed on a device, that your system will recognize that device as having been seen before. This will only happen if, as part of the registration, the device must send some hardware identification. If you don't use such pre-existing hardware identifications, but you assign an ID after ...


1

This is a lot like asking why we have both a username and a password for all our regular internet accounts, when arguably just a password is sufficient. The first reason is actually contained in your question: Actually I would considered using a single API ID is more secure - since when you change , it is more hard to identify the client (as there is no ...


1

There are basically two different questions in one. Let me simplify and rephrase them: 1. If you have userId once as authentication info and once as a part of a data object which one should win? None of them should win. These are two different userIds one is user performing the action another is the data object user as a subject of the action. Think of ...


1

There are obviously dependencies between the handlers. One possible way to do this is to assign priorities to the modules - good thing is that it is easy to implement, but (as Frank Hileman noted) this solution is not scalable. Essentially you hide the dependencies between modules from the system and solve these dependencies yourself by manually ordering ...


1

I had the pleasure a while ago to work with an API that had documentation that was very, very hard to understand. Once I managed to get an actual reply from the server, it was possible to compare the documentation with the server reply and use that to decipher the documentation (and yes, deciphering it was the right term). The problem was that if a request ...



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