Hot answers tagged

203

Reluctance to modify code for the sake of testing shows that a developer hasn't understood the role of tests, and by implication, their own role in the organization. The software business revolves around delivering a code base that creates business value. We have found, through long and bitter experience, that we cannot create such code bases of nontrivial ...


111

Checking for uniqueness and then setting is an antipattern; it can always happen that the ID is inserted concurrently between checking time and writing time. Databases are equipped to deal with this problem through mechanisms like constraints and transactions; most programming languages aren't. Therefore, if you value data consistency, leave it to the expert ...


75

It's not as simple as you might think. Let's break it down. Writing unit tests is definitely a good thing. BUT! Any change to your code can introduce a bug. So changing the code without a good business reason is not a good idea. Your 'very thin' webapi doesn't seem like the greatest case for unit testing. Changing code and tests at the same time is a bad ...


57

It depends on whether knowing the validity of some input for a task that you aren't permitted to do is a security leak. If it is, you really should to do it the other way round. The only safe response to an unauthorised user is "access denied". If sometimes the response is "bad request" and other times "access denied", you are sending information to an ...


50

Those two technologies have a very different purpose. REST is for ordinary calls to an API, with client being an active actor of the exchange. When the client needs to find GPS coordinates of an address, the client initiates the call to the API and waits until it receives the coordinates, or a error occurs, or a timeout elapses. Web sockets are for ...


46

In your latter scheme, you keep verbs in the URLs of your resources. This should be avoided as the HTTP verbs should be used for that purpose. Embrace the underlying protocol instead of ignoring, duplicating or overriding it. Just look at DELETE /item/delete/:id, you place the same information twice in the same request. This is superfluous and should be ...


38

When both sides have good arguments and the opinions on the issue are too strong to come to a consensus, you as a manager need to make a decision and end the debate. Otherwise it will just turn in circles and fortify the positions of all participants even more. The longer you wait, the harder will it be for the "losing" side to admit defeat and work ...


38

I think what you call “fail fast” and what I call it is not the same. Telling the database to make a change and handling the failure, that is fast. Your way is complicated, slow and not particularly reliable. That technique of yours is not fail fast, it is “preflighting”. There are sometimes good reasons, but not when you use a database.


37

Great question! I'm always looking for a better way to structure my projects.. Each point you raise has merit and having explored a variety of solution structures I have to say that I agree the majority of the comments here: there is no perfect solution. A few things to ask yourself when faced with this kind of problem: How complex is this application? ...


36

A PATCH request can be idempotent, but it isn't required to be. That is the reason it is characterized as non-idempotent. Whether PATCH can be idempotent or not depends strongly on how the required changes are communicated. For example, if the patch format is in the form of {change: 'Name' from: 'benjamin franklin' to: 'john doe'}, then any PATCH request ...


28

If you allow a client to access the database directly - which they would do, even with a database abstraction layer, then: You get a coupling between their code and yours - particularly, there is a very strong coupling between your database structure and their code; Your client may do some pretty undesirable stuff on your database - whether it be updating ...


24

You are right, there is no clear benefit to introduce a REST API layer between a web app and a database, and it has a cost in complexity and performance overhead. The reason you are getting contradictory answers is confusion about what is the 'client' in your architecture. In your architecture (if I understand it correct), you have browsers interacting ...


24

Well, there are multiple types of validation: Cheap basic sanity-checking, which verifies that the request is not obviously malformed. This is typically at least partially duplicated client-side, to avoid futile round-trips. Anyway, it should be done before access-control to make things easier and less error-prone, as it doesn't risk any information-leak. ...


23

SOAP, REST AND PEOPLE'S CREATIVITY SOAP needs a description document like WSDL because each resource can be consumed with different messages, there are no definition on the protocol about constraints to the possible names/messages that you can manipulate a resource. For example, in SOAP your web service that allow clients manipulate an user can expose the ...


19

The most direct quote I've found is part of Scott Guthrie's announcement of the MVC 4 roadmap, back in 2012, (apparently offline but available via the Wayback Machine) which contains the following quote: Json.NET: We plan to use the community developed Json.NET serialization stack in our default JSON formatter in ASP.NET Web API. Json.NET provides the ...


18

Given that: The two "big name" implementors, Netflix and Ebay, abandoned it a couple of years ago and excitement for OData pretty much died with their departure, OData is a RESTful way of exposing a query mechanism through an abstraction layer. Such abstractions are now widely seen as leaky abstractions, which are a clear anti-pattern, I'd suggest OData is ...


18

TLDR; Remove null properties The first thing to bear in mind is that applications at their edges are not object-oriented (nor functional if programming in that paradigm). The JSON that you receive is not an object and should not be treated as such. It's just structured data which may (or may not) convert into an object. In general, no incoming JSON should ...


18

Designing code to be inherently testable is not a code smell; on the contrary, it is the sign of a good design. There are several well-known and widely-used design patterns based on this (e.g., Model-View-Presenter) that offer easy (easier) testing as a big advantage. So, if you need to write an interface for your concrete class in order to more easily test ...


17

Is CQRS a relatively complicated and costly pattern ? Yes. Is it over-engineering ? Absolutely not. In the original article where Martin Fowler talks about CQRS you can see a lot of warnings about not using CQRS where it's not applicable: Like any pattern, CQRS is useful in some places, but not in others. CQRS is a significant mental leap for all ...


15

Update: I have edited the answer a little bit, because it may have lead to confusion. Going with an empty string is a definitive no. Empty string still is a value, it is just empty. No value should be indicated using a construct which represents nothing, null. From API developer's point of view, there exist only two types of properties: required (these ...


15

This started as a comment but grew too large. No, as the other answers have stated, this pattern should not be used.* When dealing with systems that use asynchronous components, there will always be a race condition where the database (or file system, or other async system) may change between the check and the change. A check of this type is simply not a ...


14

The first one. A URI/URL is a resource identifier (hint in the name: uniform resource identifier). With the first convention, the resource being talked about when you do "GET /user/123" and the resource being talked about when you do "DELETE /user/123" is clearly the same resource because they have the same URL. With the second convention, you cannot be ...


14

Your post should be a single, self contained action that succeeds as a whole or fails as a whole. Therefore if one item contains an error you should reject the entire set. You should also be checking these items if at all possible before even starting your database transaction so you have the chance to error out early. Of course, if your database engine ...


13

Assuming both sides are 100% correct in all of their arguments, which ones matter? WCF models are not POCO, because of [DataContract] & [DataMember] and those attributes Do you care? Are you planing on doing something that requires POCO? WCF supports distributed transactions Again is this something you are going to use and need to build if you ...


13

You can use anything as JSON keys, as long as it is valid UTF-8, doesn't contain zero code points, and it would be useful if you could represent the key as a string in the programming language of your choice. I might recommend not to use different Unicode representations of the same string (for example "Ä" written as one or two code points). Reading some ...


13

There must be some validation before access control. Let's say SO's API has an endpoint "edit answer", then whether the user can edit a particular answer can depend on the answer (below a certain reputation, a user can only edit his own answers). So the "answer ID" parameter being well-formed must be verified before the access control layer comes into play; ...


13

It is IMHO very simple to understand that for creating unit tests, the code to be tested must have at least certain properties. For example, if the code does not consist of individual units which can be tested in isolation, the word "unit testing" does not even start to make sense. If the code does not have these properties, it must be changed first, that is ...


12

I know it may seem like you are converting objects back and forth all the time between your database objects, your data transfer objects, your client objects with validation logic and so on but I'd say that no, you're not doing anything wrong. Each of these objects may represent the same unit of information, but they have very different responsibilities. ...


12

Warning: big post, some opinions, vague 'do what works best for you' conclusion Generally, this is done as a means of implementing 'hexagonal architecture' around your database. You can have web applications, mobile applications, desktop applications, bulk importers, and background processing all consume your database in a uniform way. Certainly you could ...


11

Put my two cents in. As a manager, you should ask your teammates to keep in mind the Yagni principle. This will help to reduce the list of reasons brought forward by both Teams. Our usage would be mostly for web, and we would expose our services over HTTP. In some cases (say 5 to 10 percent) we might need distributed transactions though. Rather ...


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