Is there a more "standard" way of designing this?
By default, REST focuses on returning resources themselves, rather than specific validation results involving those resources. So no, there's no real standardized way for this.
That being said, many REST APIs tend to somewhat deviate from pure REST, so it's not unreasonable to implement a feature ...
To explicitly answer your questions.
Do i have to check this from the backend? and... Do i have to check this in the use cases?
Yes, with web applications, you'll always want to do authentication/authorization based activities on the backend. This is because you cannot trust web clients to be secure. For instance, in Chrome, a user could use development ...
Should an artist paint based on commissions, or should they paint what they want and then sell it?
Should a contractor build prefab houses, or should they build custom blueprints?
Should a doctor be visited by their patients, or should they visit their patients?
All of these questions are the same. There is no specific answer to them. It depends on what your ...
You have a HTTP API. Probably RESTful one, but there's no need to jump to conclusion.
There are three point of views in play:
API is usually consumed by other code. This means that API is consumed by someone who wrote the code. A programmer. Or a tech savvy user. It would be a good user experience for them to provide as detailed error message as possible. ...
The problem in focus here is one of semantical naming, not of technical implementation.
First of all, because I get the feeling that some commenters may have made a wrong inference, GetOrCreate is slightly misrepresentative name for an algorithm that should be called GetIdOrCreateAndThenGetId which is obviously not a great name, though pedantically more ...
What is practical approach to this situation?
It sounds to me as though what you have is a command (RegisterUser) that will be a no-op in the case that the registration has already happened.
it seems like an anti-pattern
Not so much. In a distributed system where your message transport is unreliable, the capability to recognize messages that have already ...
The actions embodied by REST center around create (POST), read (GET), update (PUT) and DELETE, operations on a resource. No action or verb in the REST dialect means "calculate". I would even venture to say that this kind of operation is not RESTful to begin with, since you are not interacting with a resource. You are interacting with an algorithm.
Adhering to CQRS architecture and respecting REST design, if we have the POST invoke a Query first, it seems odd to have a POST that is statistically more likely to be making database queries and returning results. This Query-invoking-POST is more often than not acting as a GET
So remember REST is about state transfer between the client and the server. How ...
I don't know that there's an authoritative answer, but I think we can probably turn up a few sources that will at least imply that you are trying to solve the wrong problem.
As a warmup, I'd suggest a review of Parse, Don't Validate by Alexis King
a parser is just a function that consumes less-structured input and produces more-structured output.
REST doesn't care what spelling conventions you use for your resource identifiers (so long as they conform to the production rules described in RFC 3986).
In particular, there is no rule that says that, when you create a new resource, it needs to have an identifier with features similar to any other resource identifier.
I don't understand how I could create a stateless REST API that meets these requirements.
Stateless, in the context of REST, means something very specific:
each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server.
It's perfectly normal to have ...
We are developing a serverless application (AWS API Gateway, Lambda, and Dynamo) keeping users and groups in the same microservice as they are being stored in the same DynamoDB table.
Is it okay to have endpoints with different "base" in the same microservice?
From the perspective of REST: yes, of course. An important idea in REST is that we ...
No, its a pain in the arse to parse the ids out of the string afterwards. Which you often want to do for logging or routing.
Try and keep the depth and the syntax of your Urls constant
Now I have a pattern which will match everything
What's the best practice around updating information received from the request?
What a PUT message means (semantics): replace the representation of the target resource with the representation in the message-body of the request.
What the server should do when it receives a request to replace the representation of the target resource? Whatever you think is ...
A PUT request always places one thing in the service.
You need to decide what that one thing is. Two of the choices are:
The thing is a specific property, and the system has ways of selecting sets of properties.
The thing is a specific object with a number of properties.
If you select one path, you can easily PUT new properties independently, at the cost ...