Hot answers tagged

8

The problem with supporting GET /companies/{id}/employees/{id} and GET /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 ...


6

The "right" answer would almost always have edges authenticate with some sort of user account or other auth mechanism. Why? Because you can limit access of that specific edge interface to only the data they need with the right scopes. For example, a worker only updates orders but can't see payment info. If there was a compromise of the worker it can't ...


6

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/...


6

View is a layer responsible for displaying information which may be interpreted by a user/client of your application (it does not say the user has to be an actual person). JSON is completely valid format for a view layer, computers understand that. As long as the view layer publishes information which can be used by a user to affect models in your ...


6

Is there really no other truly RESTful way to get the data you need in 1 or 2 requests? Not really But don't over think it As usual, when thinking about REST, keep in mind that there is a reference implementation (the world wide web) that you can check against. Consider the Amazon portal - when I open that bookmark with an empty cache, I see my browser ...


5

The question is how should the rest api be designed if we wish to obtain the distinct list of cities? GET /cities Trying to do a God resource that returns all your resources depending on the query string is a bad idea and breaks REST principles. Query strings should filter the specific collection of a resource (ie turn all people into a specific subset ...


5

Ajax and rest are indeed two ways of using HTTP. But you can use both together. HTTP (HyperText Transfer Protocol) is a protocol to send files (and data) from the server to the client. Originally it was intended to send static HTML files from the server to the client when the client's browser requested a (HTML) page. The HTML can contain hypertext links ...


4

Add it on to the resource. If you end up with so many of these "does this special promotion apply" questions that the resource ends up huge, split them out into related resources. For instance, GET /member/{id}/promotions. Rather than relying on URL structure, you may also wish to try using Link Headers to communicate via the /member/{id} resource where its ...


4

You would typically POST a JSON or XML document with more complex data.


4

MVC is a paradigm from the Smalltalk world concerned with how object orientated systems could have UIs. Early web frameworks took the general idea (separate out business logic, controlling logic and view logic) and applied the principle to how they structured the web application. Before this it wasn't uncommon to have God awful mess of HTML generation code ...


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.


4

Static class methods are basically global functions, and are considered a bad idea in OO design. The reason why they are considered bad is hard to see in a simple code example where you are just comparing the difference between calling the same method on an instance or on the class itself. But when you get into slightly more complicated design global ...


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 ...


3

Here is how I design similar system : Client : ios/Android/other mobile clients interact with my API to make some orders or view orders API : Backend Restful service which handles the requests from clients and UI. If the orders need to be processed asynchronously then we should use Queues, from the question I get that the orders are handled asynchronously....


3

If we're talking about JavaScript then yes, it is a good idea, because it's, sadly, the only tool at your disposal. Think of your REST API as a public website. When you are creating a website and you do not want users to do something, you do not implement that functionality or forbid certain users from using it. With a REST API which should have public ...


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

Frameworks/SDK's probably use instantance methods because it makes dependency injection possible, which is not really the case for static methods. However, if you don't use DI, a static method is the simplest way. KISS.


2

While agreeing with most of the answer from @Minjun.Y, I think I would go take a slightly different approach to the REST and Web page layer. From my reading of your question, I think you are wanting to expose both a web interface and a REST interface to the outside world. There is little to be gained by reading POJOs from the database, turning the data into ...


2

Here is one of my favorite kick-off examples of structure for your spring rest app. 1. Separation of layers, each layer is an individual module/project REST API Packaged as war It has rest controllers that handle request/responses depends on Service Module below Service Packaged as jar Business logic abstractions, this layer has no idea how to ...


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 ...


2

A database with ACID guarantees is almost certainly a better way to do this than attempting to maintain an ArrayList in memory, for several reasons: It will scale. It will maintain REST's stateless guarantees. You don't have to worry about the dog tripping over the power cord. The concurrency is already done for you. If you need extremely fast turnaround ...


2

Semantically, I would consider a password change a POST. Why? You're not updating an entire resource (i.e. a User), but merely a property on that resource, a property that doesn't really have much to do with the resource's characteristics (like their address or hair color), except insofar as said property influences their ability to access the system. ...


2

WCF uses SOAP, which has a lot of overhead to use. In this case, you would probably need to auto generate clients for particular platforms, because it would be too much work by hand. There are a lot of features in WCF, but it has generally fallen out of favor due to the communication overhead and code required compared to simpler models like ordinary HTTP ...


1

Is that how it is should be done? Passing the JSON as a view, or using it as a view model to construct the view does not violate the pattern. I am using the same architecture in the current application I am working on and it is working very good. Together with some nice JS framework you can create some really responsive designs. Or are there any other,...


1

In this particular example, I think most people would choose option 1. And indeed it feels more natural to me too. Buy why? Not sure there's going to be a definitive answer to this, but my guess: because password, the entity, has a relatively straight forward representation as a document; HTTP's raison d'etre is document transfer, after all. It's pretty ...


1

Don't get too caught up with the way things are usually done, an API can be restful without having to have resource identifier specified in the URL. In your case I would say its perfectly acceptable to place the path(s) in the POST body.


1

Most usually yes. In fact, it's usually the simplest solution, because the authentication and authorization mechanisms need to be built and tested anyway. And, I'd argue for it being the default solution unless compelling reasons surface to bypass the normal auth* rules. The alternative is to add another set of authentication and authorization modules, ...


1

The reason it hasn't been answered is that it appears to be mixing different levels of abstraction. It is common to have different categories of users. In this case I see three categories of users of the API: Web App Client (may use different interfaces than the Web App) Workers (may access the APIs using a Web App or client) It may be better to ...


1

I've always had the fleet of workers interact directly with the database (or queue, whatever has the order state), which might simplify access. But in logs, you want to make sure you can name and trace back to workers, for auditing an order flow. Also, you need to synchronize the workers doing work, and clients grabbing state via the API. If you have a ...


1

I wouldn't mind making an endpoint like /member/{id}/eligibleForFreeTraining and just return a true or false but that is not CRUD or REST. REST is not CRUD. REST is REpresentational State Transfer. You are transferring the state of resources between the client and the server. What the client or server does with those representations is up to it. At ...



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