Tag Info

New answers tagged

1

To me the best solution seems to be a method that takes an optional parameter that allows the caller to determine whether or not to include the follower data. In this way the caller can determine if it is appropriate to include the follower data in the call. In a worst case scenario you have a few extra lines of code that never matter because the call ...


0

It is more convenient for you if you grab all the relevant data (about the user, the followers, etc.) in just one routine. You don't have to worry about the partitioning of the access among several calls, or having some information available and some not, etc. But having one big, honking call that takes a (possibly) long time to execute, and consumes a lot ...


2

If I want to add support for Protobuf then I have create new method in processor and copy-paste almost all the business logic NO! An object oriented approach ItemProcessor "has all the business logic". Don't pollute the class, keep it strictly business logic Your data/response structure is universal. JSON, XML, protobuf are just different syntactical ...


2

To disagree with the accepted answer: using the Authorization header seems like the right thing to do. It's the entire purpose of the Authorization header. From http://tools.ietf.org/html/rfc7235#section-4.2 : The "Authorization" header field allows a user agent to authenticate itself with an origin server -- usually, but not necessarily, after ...


1

I wonder each input parameter is different or not. Anyway you may be able to return result as Object and cast it. Also you may be able to get parameter as Object. You may be looking for that how to generate methods in runtime. http://stackoverflow.com/q/6680674 I recommend you'd better make all methods. I think It may be good for readability.


1

First of all, whatever you do, please use unique ids. In your current scheme you can only reference an entity through the exact path through the tree, that is generally annoying to work with. What happens if a person is moved from one department to another? Or if there is a department restructure? Nothing will retain its handle. Second, don't make entities ...


0

REST has many technical benefits, and it's not just about "style". It's an architecture, a way of thinking, that has many benefits over an rpc-style architecture. REST is also MUCH more than just a URI scheme. REST provides 5 "constraints" that help guide toward a good API: 1. Client–server Self-explanatory and already the nature of web apps. 2. ...


0

You would create a restful service if there are external clients that want to access your data. Using a RESTful pattern for the service makes the API almost instantly understandable to others since REST is a very common pattern. Another situation is if you want to completely decouple your web app from the server back-end. For example, if you want different ...


4

You are trying to compare two very differing technologies. Like comparing apples and oranges. It's a valid question to ask when to use REST based or SOAP based web service. For your case, I don't think there is a need of creating a RESTful web service.


1

Check out this Dropbox Tech Blog article. There they describe in detail on why and how they implemented exactly the solution you proposed for retrieving the thumbnails for all your pictures. It should be said that they do measure performance to see if it's worth the trouble, and apparently it is. Short summary: The Dropbox website has to load hundreds of ...


2

In short: Your approach is somewhat correct and could benefit from a wrapper Service. This service will combine existing single calls into one service side method. Doing that by combining calls from client to service side & utilizing all single, atomic, restful calls that you probably have in place by now. Thus, you would continue to have benefit from ...


10

One of the advantages of REST is the ability to cache the requests via traditional http caches (assuming that these are cacheable requests). When you have single, larger, less frequently used, and possibly different requests (I'm going to fetch items a,b,c,d this time and items a,b,d,e next time) you make the request more likely to be a cache miss and get ...


7

Your intuition is somewhat correct -- by and large making fewer requests is certainly preferable; chunky APIs tend to be better. Especially with spotty connectivity where you can see some work and some fail creating nightmarish fallback scenarios as nothing can rely upon anything. There is one big caveat -- you can get way too chunky and your calls and ...


0

We faced the same issue and, as others suggested in comments, we made our POSTs idempotent. You can return a different code (in the 200 family) if the file was already there, just to inform the client (or you can just answer "200"). In our experience, this also plays nicely with "not-so-connected" devices (smartphones); if you need to retry a submission, you ...


2

as long as it is ok that the app does not work when there is no networkconnection available (similar to a web-page) your app does not need to store additional info like "user has seen this info at 15:30" you donot need to implement a cache. if you want to cache the data for faster access why putting it into a database with complex datastructure? isnt ...


0

Well I would add caching to your DTO. DTOs are stateless, so always poke the database, unless a cached value exists. Security is not an issue; you can always cache reports by users.


0

So now I found out that you can actually signal changes in the link relation types. The RFC for link rels allows you to specify more than one link relation per link: { _links : { "sum-of-rows has-changed" : { "href" : "http://..." }, "some-other-link" : { "href" : "http://..." } } "value" : 5000.0 } In this case the has-change ...


1

Well, the client-side is still served from the application server, isn't it? So basically what you need is ability to provide some parameters to it. Obviously you'll need to substitute the server URL. Most look can be modified just by loading appropriate style sheets (CSS), which is just another replaced URL. And one more replaced URL can give you ...


0

If you really want to separate for whatever reason the current workflow from where the result is presented, you could use the links-section in the JSON-Response. { "name": "currentStep", ... "links": [ { "rel": "self", "href": "/api/job/currentStep" }, { "rel": "previousStep", "href": ...


1

The situation you're describing (using queues and polling) will definitely work, but as long as your external API takes only a few seconds to return a response, I think there's an easier way: As you described, it's a good idea to have your webpage response not include the data from the external API, because this allows the page response to be sent more ...


3

I would store this next to your authentication. If you are using OAuth 2.0 Tokens for example you could add an Claim where you set the customerId. If you are using cookie based authentication I would set the customerId inside a cookie and resolve it every request. This way you don't keep any state on your server, but always have the CustomerId available. ...


2

It depends. Is the response an answer to a query that's more like GetListOfProducts() or GetProductIndex()? Is the result intended to be iterated over or used as a single-product lookup by id? Is the sort-order significant? If it's more like GetListOfProducts() with sort-order implications and/or the intention of iteration, like displaying the records in a ...


1

I would put it into the Service layer. It doesn't make sense for you to do it in a NEW Controller. You can even do the remote call directly in your controller if you are sure that other controllers don't need to do a similar thing.


3

Although the right solution depends on your context, here is my approach: When designing classes one should always consider their single responsibility. In case of the PostsController it could probably be described "create, read update and delete" posts. Formatting of the output is a global problem of your application that should not be solved individually ...


1

You have outlined the two main approaches, and each have their advantages and disadvantages. If you combine both in the same controller, and all you are doing is changing the output, then using a single controller makes sense. The logic is the same, but the output changes. If the logic has to change because the output is different, then go with two ...


3

The answer is in the RFC describing the PATCH method: In a PUT request, the enclosed entity is considered to be a modified version of the resource stored on the origin server, and the client is requesting that the stored version be replaced. With PATCH, however, the enclosed entity contains a set of instructions describing how a ...


4

In most REST APIs, the type of object is not embedded in the payload. That is the job of the resource resolver. Your "master registrar" is equivalent to the typical path resolver found in web servers, except for using embedded types instead of paths. So instead of your format: POST / { topic: { property1: "value1", property2: ...


2

The HTTP spec's definition of POST is very broad. There are two clauses that make it good to treat as the "create" verb. It is the method for "append" to a database It is the method for general "data processing" So for REST, the sense of POST is that it's for appending to a collection of resources. In your example, POST to "/topics" is perfectly valid ...


2

404 indicates a resource is not found. A more appropriate response code would be a 409 with a body containing more details if the nature of the conflict.


1

404 means resource not found. Using it here would be not appropriate. Because the resource clearly exists, but cannot be manipulated. According to Quick Tips (http://www.restapitutorial.com/lessons/restquicktips.html) 409 Conflict would be a good way to go. You can of course return 200 with error message in the body. The client is still responsible for ...


1

Before I answer your question, a couple of points about your example: REST is based on resources, so the ID for e.g. a User resource would usually be part of the resource path (rather than a URL query parameter): GET /user/1 Inserting is adding an entity to a resource collection, so to insert into e.g. a User collection you'd usually use something like: ...



Top 50 recent answers are included