Hot answers tagged

7

CLI programs often resort to file or stdin based input when data is more complex than can be properly communicated via command line. For example, GNU grep allows multiple patterns on the command line, but also supports passing patterns in a file. If your data is nested as in your example, writing it down within the limitations of the command line is error-...


4

You mix a couple of things here, let's go in order: 1. "Event sourcing" is not a competing thing to "REST Endpoints", they have absolutely nothing to do with each other. "Event sourcing" is just a storage strategy for things that are best represented as a series of changes, instead of the end-state. "REST API" (I think ...


4

You could manage it in code by creating v1 and v2 packages with the functionality that differs and having some code to decide which version to run from the controller level. It is entirely possible, but it will be hard to keep track of even with a high level of discipline. What you might consider doing is maintaining long running branches for v1 and v2 in ...


3

A full test suite should contain three levels of tests: Unit tests Integration tests End-to-end tests Automated testing for REST APIs is typically done with integration tests, exactly for the reasons mentioned in the question. The unit test rules do not apply for integration tests.


2

my unit tests are not atomic since they save and load certain variables into a persistent file Persistency is orthogonal to unit testing. Unit tests should not be using any kind of persisted or shared state. The simplest example here is your car. Suppose it doesn't start. What's broken? Well, you can't know that. It could any of the many parts in your car. ...


2

As for automatic testing, what you are missing is the capability to either a. Regenerate the datastore in a very specific state during the testing phase, so you can provide each test with the required data and the required state. If we were speaking about databases, I would suggest implementing in-memory databases alongside with some sort of change logger. b....


2

For an efficient solution you need to be able to put the authorization and pagination constraints into the database query, and have the proper indexes for those aspects. Anything else will potentially overfetch an enormous amount of data. How big an issue this is depends entirely on the scale and characteristics of your data. Can you translate the ...


2

POST /api/users seems to be sufficient. Either way you have to run validation on the server side. So you can return 400 Bad Request whenever you found something wrong with input or it didn't pass business-logic validation. Otherwise, you would return 201 Created with header Location <new user id> such that consumers of your API could know the ID of ...


2

Are there other/better standard technologies/ways to prevent duplicate logic? Not really. Removing duplicate logic from the client depends a lot on: the way you build the API; the way you document the API; discipline of the client developers. The first point is obviously about the same approach as HATEOAS, to have the server API drive the client: these ...


1

Depends on what the semantics of your resource should be, i.e. what the clients would expect. Is it "normal", that the clients would call with input parameters for which this calculation can not be performed? If yes, code 200 will do, since your service performs as requested. In this case the client must expect the server to not perform the ...


1

You really only have a few options on how to handle something like this. The first is to change the API so that it accepts batch operations. If you had something like this: POST /todos/position/$batch { "operations": [ {"id": 2, "position": 5}, .... ]} You could apply them all or rollback at one shot. Another ...


1

REST is an API architecture pattern; REST APIs are distinguished from other APIs by their design. They offer a standardized interface for interacting with data resources. A REST API for a financial institution would be structured similarly to one for a hospital system; different problem spaces, but similar API design. Any REST or non-REST API can be used ...


1

Try to think of RESTful resources in terms of business entities, not database entities. So if "database-credential"s are always dealt together as business entieties, I would recoment to use /database-credential in APIs. If at all you need to deal with whitelist IPs or connection passwords independent of each other you can also add resources for ...


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