New answers tagged

0

To answer your question directly. No, a pure RESTful web service is not required for an angularjs app. It will work just fine with more RPC like interfacing also. I would never recommend anyone to pursue pure RESTfulness, especially the HATEOAS part is just a waste of time and effort. Noone will work with your API that dynamically. Until you have concrete ...


3

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


0

Ah, I see. This sounds like a PUT request would be the way to go, then. Semantically, a PUT request is made when you know the resource URL you're going to hit, and you want to either create or update the resource at that URL. Alternatively, have different endpoints based on whether a user is registering or logging in (which is how most sites do it).


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.


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


0

It seems you have a fairly standard use case and you don't have a lot of experience with API's. In that case it might make sense to use one of the available frameworks which supplies you an API so you can focus on the business requirements. It also looks like a safer way to go and will give you some experience on possible implementations. The security ...


5

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


0

You should take a look at the JAX-RS spec and do a tutorial. I like running Jersey but there are many implementations. Do not reinvent the wheel and try to build a RESTful interface using hand-rolled servlets. This will make building your REST interface a snap. Integrating to Hibernate is just writing the code to do your queries. The JAX-RS spec allows ...


0

Advantages: For particularly complex APIs, this can simplify the implementation for Front-End devs. As an example, it could hide any authentication / session management, allowing Front-End to build an object with the authentication parameters and then use a getData() method which can create new sessions as needed. It can allow your API to be more ...


0

You can use API clients to abstract away some of the HTTP details from consumers (resource URIs, handling response errors, etc.) It is usually simpler to call a simple method on an object and get a result back than building an HTTP request and managing the response. This might be seen as spoon-feeding the consumer devs, but can be suitable for less ...


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

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


-2

Can anyone explain what are the basic design decision on why API client should be used. What are really nice use cases for such a pattern etc. If you have 3 customers, with different implementations, how will you separate your code? Will you write 3 different web sites, and merge your changes? Will you write optional parameters? I hope not. A reason ...


0

Now I have following questions, while I am in front of a black board, to design a feasibility study:- Is it a feasible idea to make my above scenario as a REST service and create reports based on that? Is caching possible in such scenario? Is tools available to generate advanced reports based on multiple REST Resources? It sounds like you need ...


0

MVC is pretty straightforward. Martin Fowler would, perhaps, disagree with this: Different people reading about MVC in different places take different ideas from it and describe these as 'MVC'. Moving on... When we create a website, it all come together as 'client sends REST keyword request to server -> the server matches the requested URL to ...


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


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


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

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

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


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


0

It's actually pretty simple, a Synchronized version will do just fine, it will make all access to the list safe EXCEPT in the case where you need to iterate over it. If you need to iterate over it, there are a couple ways. Create a copy of the list then iterate over the copy (Note this will only copy the list's pointer array, not the objects in it--pretty ...


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


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


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


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

The point of a database transaction is so you can be sure that several facts within the database are true simultaneously, despite there being other users writing to the same database concurrently. Take the cannonical example of transferring money between bank accounts. The system must ensure that the source account exists, has sufficient funds, the ...


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

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


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


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


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


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


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

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


-1

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


2

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



Top 50 recent answers are included