Reputation
4,559
Top tag
Next privilege 5,000 Rep.
Approve tag wiki edits
Badges
9 18
Impact
~210k people reached

  • 0 posts edited
  • 0 helpful flags
  • 699 votes cast
9h
comment REST API - omitted properties in POST request: How should they be handled?
I agree with @CodesInChaos. Read the HTTP RFC and you'll see that PUT and PATCH are much more explicitly geared towards modifying a resource than POST. But sure, you can use POST for modification if you extrapolate from assertions in the spec that are particularly vague.
1d
awarded  unit-testing
1d
comment REST API design for web pages with wizards
You're welcome. By the way, the "two table" approach isn't mutually exclusive with this. Having one HTTP resource per step doesn't dictate your object model on the application server, let alone the database schema. It's just a Web representation.
2d
revised REST API design for web pages with wizards
added 3 characters in body
2d
answered Unit Testing and 3rd party packages. Do I mock or not?
2d
answered REST API design for web pages with wizards
Feb
9
answered DDD: Saving changes from UI to domain object
Feb
5
comment How can I create a RESTful-style website if HTML forms only allow to use GET and POST?
No one is forcing you but the whole ecosystem is geared towards it. HTTP is an application protocol, not a transport protocol. Ignoring it can lead you to hiccups in the HTTP chain such as those listed in the "Other considerations" section of the answer I linked to.
Feb
5
comment How can I create a RESTful-style website if HTML forms only allow to use GET and POST?
@Ewan Unfortunately, that's how the web works. We're stuck with it and might as well embrace it since he whole HTTP food chain (clients, proxies, caches, servers) is built around those verbs. The fact that PUT isn't supported as a form method in current HTML standards is an entirely unrelated issue.
Feb
4
comment Bulk update: return all results or only failures
Yes. The difficulty resides in coming up with a good resource name for [a large number of items that you update at once]
Feb
3
answered Bulk update: return all results or only failures
Feb
2
comment Python Micro-services Architecture
If you want to go microservices, you might need to rethink your system in terms of vertical business areas (Bounded Contexts) instead of horizontal technical layers. "a Flask webapp serving data of all micro-services to the REST APIs" sounds like overcomplicated technical duct-taping.
Feb
1
answered Domain Driven Design and Cross Domain interaction
Jan
31
awarded  Yearling
Jan
27
answered REST API - Handling subresources
Jan
26
comment How to model Aggregate Roots for this music event system?
There are hundreds of ways of modelling this depending on the use cases and domain rules. What are things that will change together ? What are some domain invariants ? DDD is good for complex domains, what makes that domain more than a bunch of data containers ? You seem to put CQRS aside but if all your complexity resides in querying a lot of data and the rest is CRUD, it may well be CQRS you need instead of DDD.
Jan
19
comment Does discoverability in HATEOAS require the information must be machine readable, or can it just be human readable?
What do you mean by "machine readable" ? That a machine has all it needs in the response to construct the next request to follow one of the links ? Or that the machine is able to determine by itself which link to follow next ?
Jan
19
comment Does discoverability in HATEOAS require the information must be machine readable, or can it just be human readable?
The OPTIONS method lets the client know which verbs are accepted by the server on a given resource :)
Jan
19
comment Status transitions with extra information in RESTful interfaces
@VoiceOfUnreason "Ceci n'est pas" different resources ;) It's the same resource that can be accessed through different URIs depending on its state.
Jan
19
comment In REST is HATEOAS really about self-discovery or about navigation?
Regarding your aside, I find the Richardson Maturity Model to be a good representation of the nuances of REST you can get. Of course, if you ask Fielding, the only true REST is one that enforces HATEOAS, but in practice, few teams bring their implementation to that level of rigor.