Hot answers tagged

7

The problem here is that Tim Bray doesn't explain why he thinks it's not idempotent. The concept of idempotency is somewhat subjective. When we call a PUT twice there are a number of things that aren't the same as when we call it once. For example, the server access logs will be different as well as other logging. There might be other side effects to the ...


6

The idea that App 2 makes a request back to App 1 is a common architecture to get web services to work together. Usually, this would work like this: App 1 makes a request to App 2 the request contains an URL on App 1 to be called upon completion App 2 responds to the requests, and begins background work eventually, App 2 requests the URL provided by App 1'...


4

I would favor a PUT verb on the transaction endpoint to manually set the transaction category, as @keelerjr12 suggests.. However, you need to have a clear understanding about the transaction categorization workflow. I presume that categorization is a heuristic algorithm, so it might be unable to find a category, and it might also err by assigning an ...


3

Does this follow the standard way for building a RESTful API under this type of scenario Yup, that's fine. As far as REST is concerned, if the identifiers are different, then the resources are different. REST does not imply that two resources with similar identifiers will have similar representations. http://localhost/priceMetrics?startDate=2020-01-01&...


3

Reminder: the real definitions for HTTP methods are those published in the specifications that are registered with IANA. In the case of PUT, the real definitions are in RFC 7231. How do I correctly interpret that? That PUT must be idempotent? The semantics are idempotent. An important element of the REST architectural style is the uniform interface ...


2

I would do it with a queue in both directions. App1 -> queue -> App2 -> queue -> App1. I would use RabbitMQ and have multiple instances of App2 if the load increased. The problem you could have is with notifying front end, but I guess you could have some sort of polling or push notifications when the operation finished.


1

REST as a concept relies on the HTTP Method to be your verb. I.e. you GET a resource, or change it by POST, PATCH, or PUT. For simple Create, Read, Update, Delete (CRUD) behavior this maps well. If you need to create a resource, the typical interactions follow: HTTP POST to /documents On successful create, respond with 201 Created and a Location header ...


1

I like the solution provided by @blaž-mrak, as it really simple, and allows the front-end to decide what they really want. However, if you where to actually allow requesting several calculations at once, here is an idea on how to do so: By the way your code looks, you probably have some logic in your application that looks kind of like (let's call the class ...


1

I think it is not a "must", but a convention. Technically I could do DELETE /users in my app to fetch the list of users in my database. Is that bad? Not really if it is just for my use, because this will effect noone else other than me (and I mean me, as a dev amusing myself, living life on the edge, alone, not as a part of a team or working on a ...


1

In your diagram it's somewhat unclear in which direction the data flows. Your arrows are bidirectional, does that mean each participant sends as well as receives files? It is also not clear which party initiates the transfer, which party runs a server, and whether data is pulled or pushed. HTTP, upon which REST services are built, has generally pretty good ...


1

This all depends on how quickly you need changes to propagate upstream from your protected service to your clients. Content delivery networks all have some latency between telling their services to expire their cache and those servers requesting updated data. Since a CDN is distributed around the world, different regions could experience different latency ...


1

HTTP was initially designed as a stateless protocol, which means a server should not need to maintain any client-specific session state between requests. Instead all information necessary to process a given request should be included in the request itself. State between requests should only exist on the client side. The cookies protocol was introduced to ...


1

Just to disambiguate things a bit. "Application State" in REST is used to describe the state of the conversation taking place. So how far are you in your order process, on which page are you in the "wizard" or things like that. What constitutes "Application State" and just plain "Server State" is sort-of fluid. Your ...


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