Hot answers tagged

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

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


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


5

An API (Application Programming Interface) is (according to wikipedia) [...] a set of routine definitions, protocols, and tools for building software and applications. An API expresses a software component in terms of its operations, inputs, outputs, and underlying types, defining functionalities that are independent of their respective ...


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

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

The most common term, based on my experience, is internals. E.g. You will often hear C# guys speak about the ".NET internals". Similarly, a Win32 programmer might refer to "Windows internals". Though I've never heard this one, in the Linux world I would find it most amusing to hear someone say "kernel internals". Example book titles from Amazon: Windows ...


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


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

Two things to understand about CORS: CORS is not for authenticating/approving the client, it is for approving a request originating from code executing within a web page on one origin that is destined to another origin (like JavaScript code on domain1.com making an XmlHttpRequest to domain2.com). CORS enforcement is entirely client-side. The server does ...


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


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

From the documentation page you linked: Parameters since_id Returns results with an ID greater than (that is, more recent than) the specified ID. There are limits to the number of Tweets which can be accessed through the API. If the limit of Tweets has occured since the since_id, the since_id will be forced to the oldest ID available. Store ...


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

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

If you indeed want other developers to work on the actual code, then yes, source control is the solution. If you want control over what goes in, then indeed PR's seem like the correct choice. If you use GitHub you can provide comments before merging a PR


1

I wouldn't say that there are frameworks for consuming REST APIs. Frameworks usually deal with more elaborate problems than sending and receiving web requests. A lot of languages provides means to consume REST APIs. So in the end the question is what is the most convenient for your project. A software would probably be in one of these 2 categories (in your ...


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

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

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

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


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. There's precedent for that; for instance: https://developer.github.com/v3/gists/#check-if-a-gist-is-starred I could possibly add this information onto the Read endpoint but that means that its going to get returned ...


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


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



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