Hot answers tagged

11

The body. Headers are supposed to describe the request, not encapsulate its payload. Headers are meta-data.


7

You can make the code a little more maintainable if you Put the product handling logic (without permission logic and without other side effects) into a separate service class ProductDomain. (See Separation of concerns for details) Create a ProductHandlingService class that uses ProductDomain and applies permissions and other side effects give the ...


6

You'll have to find out with Google themselves. My guest is that you cannnot, in the specific case of Google Voice recognition service. That's not because it is not technically feasible but because Google simply hasn't designed it to be downloadabled and independant on the servers. As a counter-example, Apple's dictation services, that originally where ...


5

In general, a Web API is a programming interface that HTML applications can leverage for "external" resources. In practice, an "external resource" is in one of two categories: Web services: These are interfaces generally accessible over the web via HTTP(S) (e.g. REST, SOAP). They're developed by whoever builds or maintains the target server-side ...


5

Short answer: it is not true for libraries or tools "in general". Each vendor can guarantee for his library or tool whatever he wants. There are libraries and tools where the vendor does guarantee functional equivalence and the equivalence of certain aspects of non-functional requirements just functional equivalence, not more only syntactical equivalence ...


4

Consider the first case. Each client gets a random ID that lasts for the duration of the session - which could be several days if you like. Then you store the information relevant to that session somewhere server side. It could be in a file or a database. Let's suppose you pass the ID via a cookie but you could use the URL or an HTTP header. Pros: ...


3

Would it be incorrect to consider profile,address,contacts as subresources. No, anything you like can be a subresource. REST doesn't care (a subresource is a resource), and using paths is appropriate URI design for hierarchical elements. is there a completely different option to be considered? You might want edits directed to finer resources ...


3

When it comes to a large applications with huge database containing milions of records, you soon realize, plain selects, updates, inserts and deletes simply are not enough. So you start thinking in a different way. You create procedures and triggers to take care of more complicated stuff directly in the database and this is not very good. Databases offer ...


3

...if you are reliant on such optimizations, then you should make your own ... It's a bit of a tautology to say so, but code guarantees only what it guarantees. One of the purposes of having libraries is to form a boundary that's opaque to callers, and the only time there should be a complaint is when one of the guarantees isn't being met. (This is ...


2

I've looked at what a request looks like using body parameters and header parameters, and also some PHP examples (thanks to @RobertHarvey) and I've concluded that body parameters are the best way to go, as they do not require any special functions to read in PHP. I was just unsure of what they were, but now I understand completely. POST Body POST ...


2

If there's only ever one image per person, you may not need a separate image data store. You could store the path with the user. Keeping it separate doesn't hurt, or course. Regardless of how you store it, I would simply return the image path as part of the user "profile". /api/userprofile/id might return: { name: "Honey Boo Boo", favoriteColor: ...


2

Note that on the Joda-Time website it states: The standard date and time classes prior to Java SE 8 are poor. By tackling this problem head-on, Joda-Time has become the de facto standard date and time library for Java. Note that from Java SE 8 onwards, users are asked to migrate to java.time (JSR-310). The main contributor to Joda-Time, jodastephen, ...


1

Here's my opinion on the matter: You have the right idea of wanting to use a webservice, but you may be planning on using the wrong tech. When you say REST, I'm assuming you're talking about Asp.Net WebApi. That's the wrong tech for intranet applications. REST & WebApi are awesome, don't get me wrong, but for any kind of internal application, WCF web ...


1

Look at it this way, it definitely is a common pattern and might reasonably be described as best practice. Depending on your platform you may find tooling that almost makes the problem go away - Microsoft have ODATA support for connected apps that should makes forms over data straightforward once you've climbed the learning curve. More pragmatically - ...


1

If the dataset was expected to stay small, it would probably be faster to filter client-side. But because of this: Initially the data set will be low. But with time it will grow quite big and I want it to be scalable to it can be used for a long time and not break or slow down as data increases. I would recommend server-side filtering. Otherwise, ...


1

There are some fine answers here but I wanted to echo the same basic idea, yet with a twist. GPU rasterization is actually pretty amazing at rendering epic amounts of "homogeneous" primitives. For example, I don't even have a very good GPU (GTX 560 Ti) and can rasterize 4 million wireframe lines in 3D through a vertex and frag shader at over 30 frames per ...


1

Following the specification for URL laid out in the original RFC1738 or in RFC3986 for URI spec, colon (:) is reserved for specific purposes. The slashes in the path portion of the URL are there to connote a hierarchy. So while your application does not break when a route with colons in the path matches it does not follow the proposed specification. The ...


1

By discarding REST, you lose much more than just HATEOAS. If your microservices are public (and it's a good idea for them to be public or at least tend towards being public one day┬╣), using anything other than REST and SOAP would be problematic: Some developers never used AMQP, Some have used AMQP, but are often much more familiar with REST and SOAP, AMQP ...



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