New answers tagged

3

The problem with supporting GET /companies/{id}/employees/{id} andGET /companies/employees/{id}is that the meaning of the path segment after/companies` is overloaded. It would represent either "a specific company" or "a property shared by all companies". It's annoying to implement on your side, confusing for clients, and now you have to track that you've ...


3

There is no guarantee that employee IDs are unique across companies. In other words, we may run into this scenario: > GET api/companies/4711/employees/42 Smith, Winston > GET api/companies/815/employees/42 O'Brien, Seamus If we really had the case where employee IDs are a resource independent of companies (such as the SSN in the U.S.), then api/...


0

I'm having a fundamental difficulty in seeing much utility to this particular type of API in relation to SIP trunks. Do you regularly manage telephone systems for large corporations with hundreds of lines and thousands of phone numbers? If not that might be why you don't see the advantages of such a system :-) Is it really so time consuming to click ...


1

Now I'd like to check if a customer with a particular customerId exists. What do I do now? How do I name the endpoint? You don't. REST is about state transfer. You transfer a representation of the resource between the client and server (REpresentational State Transfer). You don't put domain specific logic into your URL scheme. A resource has a URL, and ...


0

I appreciate that the process can be automated Yes. That's a huge thing, because … Is it really so time consuming to click the buttons? … Programs can't click buttons. You are essentially asking why programming would be useful. On a site for professional programmers, the sample population for your answers is probably going to be pretty biased ;-)


1

Normally in REST your would get: /customers -> List of customers (We include links here in HATEOS so in this JSON you will find link to /customers/123) /customers/123 -> Full details of customer 123 (you can limit fields if you want) /customers/9999 -> If this customer does not exist return error 404 So as you see you would never get a link to /...


4

As per comments, the URL to get details of a customer is /customer/{customerId}. To check if a customer ID already in use without retrieving all the details, you can query the same URL using a HEAD request.


2

Why not both? Which is to say, yes, there are trade offs to consider, but if the marginal cost of implementing a second option is small, you can offer to your clients the ability to select which representation they prefer, so that they can choose their own trade offs (of course, there's some complexity penalty to be paid by offering a choice, rather than ...


3

A fields parameter can take care of this. In the example given in the question we could simply ask for the customerID field. If the response provides a result then it exists. From Best Practices for Designing a Pragmatic RESTful API by Vinay Sahni Limiting which fields are returned by the API The API consumer doesn't always need the full ...


3

Is concurrency and idempotency mutually exclusive for a REST web service or can it be done so a service can be both concurrent and idempotent? Yes, of course User A send same request, with Person.Version = 2 value. It fails because you expect the Person.Version value 3. I think you are confusing a couple different ideas. From Gregor Hohpe The ...


0

In a concurrent environnment, access to data is always following the Cap theorem. That is to say, you have an implementation choice between the following : Global read/write lock i.e. no high availability Local caches i.e. no consistency between clients Centralised system i.e. scale limits In a classic REST service, updates are directly sent to the DB ...


1

A chat service as a rest-ful api is a GOOD match ! I think resource-based interfaces are still a very important concept to talk about. The above answer is just not correct, even though it is over 4 years old. In general, really NOTHING is wrong about building a chat server interface as an resource oriented ReST-ful API. It is absolutely valid and a very ...


0

REST is non-functional. Activate is a verb and can not be a state, Active is a state. Because RESTful is non-functional you can not tell a RESTful service what to do, but you can add work for the queue of a service. See this: PUT /subscriptionQueue subscriptionId={subscriptionId} active=true This request is RESTful and supports all benefits of RESTful (...


3

You need to watch this talk by Jim Webber. When I need to update the state of the subscription, I cannot simply send a POST request to the server, because I don't have direct access to the resources, but I need to call some RPC-style operations to update their properties. Additionally, only and only if I'm changing the state of the subscription to "...


0

If its a boolean flag to activate/deactivate stuff, i'd say the default is to use JSON: POST /subscriptions/{subscriptionid}/ { format: 0, subscription: { active: false } } This is easily extended if you want to support more properties. Another approach is giving it its own endpoint: POST /subscriptions/{subscriptionid}/active/ ...


0

I don't know Flux, and my answer is "it depends". Edit with summary: I would choose between either (A) including attendee resrouces directly under meetings (and not optimizing as you have done), or (B) not include them at all and only provide URIs of the attendee resources. Choice (A) is a reasonable compromise in my eyes. If you're aiming to be as RESTful ...


0

I don't know what kind of objects you are serializing, but generally speaking, a binary serialization, combined with something like LZ4 compression, makes much more sense than JSON.


1

The proper HTTP error code on input is 400: Bad Request. In the response you could go with 500. If there is an error in marshalling or unmarshalling, an exception will be thrown which you can handle by registering an ExceptionMapper (scoll down to the Exception Mapping section). You can then determine what kind of error to throw. The JAX-RS package has a ...


3

You should return a 404. You can do it by throwing a NotFoundException (https://jersey.java.net/apidocs/2.6/jersey/javax/ws/rs/NotFoundException.html). Also please look at this SO question if you need to control the returned content type http://stackoverflow.com/questions/23858488/how-i-return-http-404-json-xml-response-in-jax-rs-jersey-on-tomcat


4

HTTP 204 means that something was found, but it's empty. For instance, imagine that you're serving log files through HTTP, with the requests such as http://example.com/logs/[date-goes-here]. On May 18th, 2015: http://example.com/logs/2015-05-19 would return HTTP 404, which means that there are no logs, because, well, it's difficult to log the future. http:/...


2

For your case, I believe returning { "status" : "off" } With a 200 status code is "correct". In practice, it doesn't matter much. When Fielding published his famous rant on hypertext, he called out a particular error in this way: Failure here implies that out-of-band information is driving interaction instead of hypertext. Out-of-band in this ...


2

From my understanding, the solution 1 misunderstood the semantics of the HTTP status code. From RFC HTTP/1.1: Status code Definitions 10.4 Client Error 4xx The 4xx class of status code is intended for cases in which the client seems to have erred. In you example, it's a matter of resource representation. Because you are probably thinking that a ...


3

GET /api/sprinkler that returns 200 and {"status": "on"/"off"/"damaged"/"no water".....} In my view assigning meaning to error codes which already have a defined meaning is a bad idea. How would you distinguish between "off" sprinklers and "client pointing at the wrong url" exceptions?


2

Server should expose those REST services, which fullfil your need in front-end for the single page application. When an application is developed which acts as the client for the data available through REST services, there is quite often communication between the back-end and front-end team. Because of this and the demands from the front-end team, the REST ...


1

Is there a recommended way to handle this scenaio? You need to review Jim Webber's talk on DDD for Restful systems. The basic plot - to modify your aggregates, you deliver documents (aka messages) to your HTTP endpoints, and the changes made to your aggregates are a side effect of the document manipulation. So solution (a) is heading the right direction. ...


2

I will try to be exhaustive about the possible solutions that you might use. As you wrote, I consider that a product has the following attributes : id, name, availability 1. Designing a resource for each attributes /products/555/name: GET returns the current name of the product id 555. PUT newname modify the current name of the product id 555 with newname ...


1

Do not create tokens in the business layer unless your company's business is security. It can either be its own project or part of the web api. The web api is, after all, the trust border for the application, and the tokens are likely translated (by web api) into user objects for your other layers. Ideally, you shouldn't handling this in your own code at ...


0

One way you can prevent this scenario is quite heavy handed. You could introduce minimum latency for outbound connection, say 30 ms. Within your internal network, you need to make sure that you do a series of cryptographic requests and response to measure latency, such that the access card must respond below the latency limit. Thus the card has to be ...


0

I think that IP spoofing is much easier than explained in the other answer. This can be achieved without any admin right on your network. Just the right software (or some consumer grade devices). Even hardware MAC address isn't reliable to whitelist devices. No, this approach isn't protecting anything. The client secret that you are talking about looks ...


1

I believe IP spoofing is possible, but it is very difficult. You either need administrator access in one of the servers in the same subnet as the client, or access in one of the router between your server and the end server. If you use HTTPS, the password based authentication would be enough, no one could capture the password in transit (assuming SSL ...


0

This is a really nice question. The problem arises because you are modeling redundant information and try to avoid redundancy at the same time. On the one hand, you have a collection of players players = [{"id":"1"},{"id":"2"},{"id":"3"}] On the other hand, you have a colletion of teams, which itself consist of subsets from players. teams = [ {"id":"1"...


0

For inspiration, you may want to look into the way some of the json based api's (ex: json api, HAL) handle embedding. One simple answer is to track your data in a key value store. For example { "/players/0" : {...} , "/players/1" : {...} , "/players/2" : {...} , "/players/3" : {...} , "/teams/0" : {...} , "/teams/1" : {...} } And then you describe the ...


3

It's very typical to use the domain model as the resources in the web API layer, but it's usually not the right thing to do. The domain layer has clients, including the web API. The web API has clients, including your UI. The needs and wants of domain clients are not the same as the needs and wants of web API clients. Write your web API for your clients. If ...


2

what would be wrong with treating a client session as a resource/an application state as well? There is nothing wrong with that per say, the problem comes when you try and use application state (in the form of session resources) as a form of authentication. You are basically saying that if the application is in this specific state then this client (say ...


0

I would make a dynamic scope in the model (https://laravel.com/docs/5.1/eloquent#query-scopes) which gets as input the permission and modifies the query select to return only the allowed fields for specific permission.


2

what would be wrong with treating a client session as a resource/an application state as well? The short answer is that you get unexpected side effects when the client's understanding of application state and the server's understanding of application don't match. Review Fielding: Section 6.3.4.2. Notice that, in the examples that you describe, the ...


1

Sessions are temporary data needed by an application, and are usually orthogonal to what the API is doing. Adding session management in the API distracts from the core functionality, and could introduce unrelated bugs. The best place for session data is in the application itself. However, there's nothing to say that you couldn't make a separate API to ...


3

It's common for DAOs to return the newly-created resource, particularly when an ORM is used behind the scenes, for a couple of reasons I can think of: The returned object often has its surrogate primary key set, but more importantly - The returned object is often attached to the database session so further changes might automatically be committed when the ...


3

For performance reasons, it's nice if an HTTP API call that creates a resource returns a representation of that resource to the client. Otherwise they have to do a separate GET call to get the resource. The success or failure of the request should be conveyed by the status code in the response - 2xx codes for success, 4xx and 5xx codes for errors. You ...


1

"Idempotent" means that making the call has no side effects. If the call can return an error, then it can return an error on the first request, the second request, both, or none. You might have an access token that is valid for 24 hours; a request one millisecond before the token runs out succeeds, a second request one millisecond later will fail. ...


2

According to the HTTP 1.1 specification, idempotence is defined as: "(aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request". As this definition only discusses the side-effects of the request, and not the content returned, it is acceptable to return different content.


3

You can return an error on the second put and still be idempotent in the meaning of the term when applied to the http operation PUT. In this case the idempotency refers to the end result on the server of your operation. Ie if you send two identical PUT requests only one should be actioned. The clients action on the returned result is not part of idempotent ...


2

First off, the token approach seems sound for your case. One option is to encrypt user information (e.g. id) into the token. On the server side, you can then keep things stateless. Realize that no matter the details of how it is generated, this token is sensitive. If someone has it, they can use it to pretend to be that user as long as it is valid (just ...


1

Don't really know the full use case but this really screams using a session to me. Normally these are implemented with a unique ID sent to the client in the form of a cookie and stored on the server in an in memory database like redis or memcached. When a user logs a new object will be added to redis and stored by a unique key with any user information ...


2

You asked: Does local applications running on the same machine that host the server, will have faster REST communication? Absolutely. Your data won't have to be serialised onto the wire. For faster "local" REST communications, does a server needs to expose 2 endpoints (one for localhost / one for remote) ? No. Your server will expose on a ...



Top 50 recent answers are included