New answers tagged

0

creating the same order request 2 times is undesired. Then your create operation is not idempotent. And this eliminates PUT as an option. Leaving you with POST. Semantics of PUT is basically "create or replace". And thats why it so rarely used. This is idempotent: PUT /resource/xyz with BODY1 => 2xx PUT /resource/xyz with BODY1 => 2xx This is NOT ...


1

I would avoid the ambiguous semantics of having both a resource identifier of clientGeneratedID and serverGeneratedID. I would make for cleaner semantics if the client generated ID was in the request / object body. Then you can move on to POST semantics where a POST either succeeds and returns a serverGeneratedID (usually in the location header), or it does ...


1

I'm mostly with you on the PUT design. The client does a PUT to a specific Id that they specify. If the resource doesn't exist, you create it and return a 201 response code. The question is what happens if someone attempts to PUT to that same resource again. The standard PUT semantics would be to overwrite whatever is there with the new content provided ...


0

A good practice in Json communication is to never treat a missing field any differently from a field with null as the value. If you do, you will suffer in the future while trying to maintain sanity and backwards compatibility at the same time. You can ommit null in your response, to make it shorter, but don’t rely on it in your client. Take a look for ...


2

Just do a POST with a body. You have an unbounded array "select":["eh","wt","fc"] which is going to be a pain to serialise as query string parameters and can possibly exceed the URL length restriction. I would also recommend scrapping your sproc, having a simpler method that returned more objects and moving the filtering to the client. This will take load ...


6

Just do a GET with normal parameters. You are nowhere near the limit. You may want to make a little helper function that can take an arbitrary object and turn it into a query string. The problem with 1b it is hard to debug (just changing a parameter in your web debugger becomes a chore). Also logs will be obscured. You lose out on the ability to filter ...


0

You have a great use case for GraphQl's "ask for what you want" approach. Unfortunately you'd have to break with REST's ubiquitous-ness and rewrite the client and server parts. JSON:API has formalized another approach that I like, related resource links. In this approach, links to related resources the server anticipates the client will need can be included....


0

As already suggested by others, it is reasonable to allow a city contain more than one facility of each type. One more way to allow this would be to have each type of buildings represented by a property containing array of buildings of that type. This way if you have no hospital in a city you have empty array of hospitals. This gives you much stronger ...


2

Your design doesn’t allow a city to have two hospitals, Ewan’s approach allows it, so that’s a lot better. In your example, is there a port with no information, or no port? Again, in Ewan’s version you either have no “port” entry or an entry with type=port and nothing else. The additional entry [airport, railway_station ...] has no value. At best it is ...


2

Why do you think you need to specify keys for facilities that are not present? Why not just omit them entirely. { "city": { "cityName": "Gotham", "population": "8620000", "facilities": { "airport": { "name": "Batman International Airport", "numRunways": 7, "...


5

In your case where there simply isnt a building of that type I would go for an array of Building { "city" : { "buildings" : [ { "type": "airport", "name": "Batman International Airport", "numRunways": 7, "dailyCommuters": 340000 }, { ...


3

This seems like a purely implementation question, it makes no difference to the end result but might make it easier to debug How would you explain to a client that sometimes a call returns X and sometimes Y? How would the client know which type to deserialise to? how would an application using the client know the return type of its call? It wouldnt be ...


2

My answer depends on what the intent behind the update is. If the intent is to always replace the whole object: use PUT If the intent is to update a part of the object: use PATCH The fact that in this particular case, "part of the object" happens to be 100% of the object shouldn't matter. If the call you are making will be doing partial updates as well as ...


1

We can probably redesign the Order Microservice to store and return a tailored amount of Product data along with Product reference (same for Customer data), which is needed for "Order Summary" view/response; It's not very uncommon to have same data residing in multiple systems, especially since this by nature is mostly static (i.e. Ordered Product details ...


1

In principle, each logical set of data should have its own microservice that has exclusive access to that data (encapsulation). However, sometimes it cannot be avoided to have a complex query on multiple sets of data implemented in one service, for performance reasons. In most relational database systems, you can define a 'view' to decouple the query from ...


0

This is reminiscent of historic code: queries and then loops inside loops doing queries themselves. Move the frontend methods with heavy microservice usage to the backend. Then there the prior microservice calls can be immediate calls, and all in the same transaction. This kind of refactoring can be done step-wise, parallel to the working system. ...


3

One way to 'solve' this is by re-designing or extending the REST interfaces to support batches next to single item requests. E.g.: Next to the GET server/products/314 you could implement a POST server/products/filter and post a body containing the ids of multiple products. This would reduce the number of round-trips (assuming that these are the costly ...


2

Ultimately, I think your question has roots in the common misuse of HTTP verbs. PUT It's common to equate a PUT to an UPDATE in an RDBMs but it's actually more like an 'UPSERT' (i.e. update or insert if not present). So as pointed out by Robert Harvey in comments on another answer, at first glance, it doesn't make sense to return a 404 not found in the ...


1

The URL /users/NAME/images/XYZ infers that image XYZ is a subresource of user NAME. If no such semantic exists, or this semantic relationship is not useful, then keeping it simple with /images/XYZ is perfectly fine. Now imagine what happens if the client requests /users/NAME/images. Should they get a list of images filtered by that user? What happens if the ...


5

I feel safe in saying that there is a large consensus amongst experts against using 404 to indicate that the object your API is looking for in its database was not found. The main issue is that you will also get 404 when your webserver or client is misconfigured, or you simply mistype the domain. The second is that you often don't want to throw an ...


1

The point of microservices is to get independent pieces of software. This independence serves multiple purposes like maintainability, organizational fit, scalability, etc., which you might find advantageous in your context. Splitting into services based on data, while seem to be popular, is rarely if ever a good choice for microservices. The simple reason ...


0

Yellow seems like a monolith. Red is division of microservices via functionality, which could be better mapped to a monolith. Blue and green seems more valid, as they are separated via business entities. Now, a) you can try using a Gateway, as previous stated. This will simplify matters for you. b) expose as many endpoint as you wish. This does not ...


4

The microservice architecture doesn't force you to separate things that belong to each other: Microservices should correspond to an independently deployable service. So if you would cut into parts things that really belong together, their independence would be purely hypothetical. This being said, a critical review of existing coupling is necessary because ...


0

I see what your are saying. I do have a few objections though. a) The gateway will not be synchronous. Asynchronous programming e.g. nodeJS sends a requests and when a response arrives it executes any code on the callback. So you just need to have asynchronous requests on the API gateway. Search for a asynchronous requests" in the programming language you ...


3

Aside from the subjective "pretty"factor, are there any benefits of one over the other? Perhaps in terms of generally accepted best practice, security, RESTful design, etc? There isn't much difference between the two approaches REST doesn't care what spellings you use for resource identifiers; general purpose components don't try to extract any semantic ...


0

A complex question. On the face of it, yeah, if you have a websocket connection open, you should use it for everything. If you app has a limited set of functionality which is all served by a single back-end application, and websocket is working for you already, then this is going to be fine. However. What if your get history API is a separate application. ...


2

Stripe API uses a key called Idempotency-Key for achieving idempotency ... Doesn't idempotency inherently mean that the client application doesn't need to know or care about the actions taken at all? From this POV it looks a bit useless to explicitely request such for my taste.


2

Yes and no. Idempotence key on the surface level looks very similar to nonce, but they don't overlap. A nonce should only be used once, even on a retry, you should generate new nonces. On the other hand, an idempotence key must be reused when retrying a REST request where you don't want the side effect of the update to be applied multiple times.


1

I'll admit some ignorance regarding Java's implementation of CompletableFuture<T>, but in general you may introduce the threat of deadlock due to hidden synchronization calls. That particular problem is definitely evident in C# async and await task synchronization. Hidden within your portfolioHandler.get() method is a synchronization call that is ...


0

The best I've seen (if we do not go into GraphQL and graph-based formats) is a mechanism for deferred entries in the OData. Use query string to select what needs to be fetched in full (there can be custom filters, pagination, etc). For the rest - only URIs are fetched (this also provides for HATEOAS: Application will not need to construct URLs). This way an ...


0

I think you captured the trade-offs pretty well. To make a good decision, we need to look into why we follow (anti)patterns like god class and separation of concerns. Your API client is a proxy, it doesn't do any work on it's own, it forwards the calls to another entity for processing. It's own concerns are centered around a REST API. Hence the reasons we ...


1

At a very high level, it sounds like your workflow is Download a copy of the server's current representation of the list of players Make edits to your local copy Request that the server modify it's copy of the resource to match yours. That's right in the sweet spot of HTTP; the flow would normally look like: GET /teams/myteam/players // Make your local ...


2

REST is really only well specified for CRUD operations on objects and sets. Furthermore, PUT replaces the resource in its entirety. So technically if you were to update each player with a position, you'd have to read and write all fields. Not everyone does it that way. I prefer to POST a command object, i.e. POST http://.../teams/myteam/reorder { "...


1

This problem space is called service dependencies. Documentation can go a long way, but can also be hard to come by once services are rolled out. What are you using for service registry or service locator? That might be a path to follow to mine the information you need. Two technologies have emerged that you can route API calls and through logging and ...


4

I think you might be missing a resource... have you considered a /team/myteam/player_positions resource? There are some also comments about PATCH not being supported... I wouldnt be too concerned about that if you're building both the server and the client, so use it if it makes sense for you. That being said, using PUT to fully update a resource called /...


1

Firstly, PATCH is not officially supported, so, using it would be a considerable bottleneck before even thinking about anything else. If possible, steer away from it. Secondly, before sending anything to the server, try and ensure data consistency and validation on the front-end or even UI side, anything that ensures you that before you click your Save or ...


0

Firstly PATCH is not universally supported - see https://restfulapi.net/http-methods/ I would lean towards using PUT instead of PATCH.


0

I was looking for this a few minutes earlier and I stumbled upon this question. It's weird, I was expecting to get straight to the point answers to this. So I came up with mine. I believe the best way to do it is to handle it through a 3rd party or even a second server of yours. i.e.: if you're building a mobile app, you could integrate an analytics tool ...


1

Pardon me if I've misunderstood your question, but the way I see it Newtonsoft.Json library has JObject class which actually represents dynamic JSON piece. Here's the snippet code which shows how you can query it to get only the properties you're interested in your business logic.


Top 50 recent answers are included