Tag Info

New answers tagged

-1

It is now 2015. I would have hoped that SOAP has died by now, but it still lingers like a bad smell. For anything but the most basic of "example" applications, integrating with a SOAP service is frought with challenges. It is a complex architecture, with many options at multiple levels, combined with the quirks of multiple implementations and subtle (and not ...


0

Yes, it is a fair architecture - the concept of a web server taking requests and the passing the call on to another server to process is almost certainly best practice in all cases. At least theoretically you could then hosts your logic files on one or more application servers if load gets too great. Even if this doesn't apply to you right now, its still ...


2

If an owner can grant access to other users, then it is called Discretionary Access Control (DAC): discretionary access control (DAC) is a type of access control defined <...> "as a means of restricting access to objects based on the identity of subjects and/or groups to which they belong. <...> The term DAC is commonly used in contexts that ...


0

I have always found a few large requests to be better performing and more scalable. But there are tradeoffs in all approaches, so it depends on the needs of the server and client. You may wish to use another option, which is to have the client specify a whole range or set of data to retrieve -- not necessarily all the data, but some range, which is tuned ...


0

For me functional specification of WS is just use case diagram for your backend. You can describe it as set of features like ability to authenticate user, get messages list, finish user's sesion, demand something. Functional specification should describe what (bussiness) services are available through your WS and what is it built for.


1

There are a few things that make this API not very RESTful: REST API URLs identify resources, not actions. First, actions should not be part of the URL path. The actions are the different HTTP methods. Instead of doing something like GET /api/person/findByEmail/ssmith@acmeco.com, you should remove findByEmail and use query parameters to convey that you're ...


2

As for if and how to use HTTP for the data transfer, I completely agree with MainMa's answer. However, independently of the size of the data, the process which you describe doesn't sound a like a typical application for Rest. One of the main ideas of Rest is having named resources like mycompany.com/claims/customer/{number}/claim/{number} which can be ...


1

If JAX-RS is not a requirement, then I'd suggest looking at Restlet. It uses conveyor architecture, so nesting resources into other resources is not a problem - see hierarchical URIs. When integrating with Spring, you typically define root SpringBeanRouter, in which you put actual resources, in each of which you can put another routers, and so on. You can ...


5

The answer discusses in general the aspect of sending large data over HTTP using REST. Make sure you also read the answer by Robert Jack Will which is more specific and suggests a way which makes it possible to avoid sending large data in the first place. REST has nothing to do with XML: the format of the data, would it be JSON, XML, plain text or ...


0

An easy solution is to add a prefix to all the query fields (or at least the customized). In my case the fields can be in different classes, e.g. "core" or "custom" so it is convenient to use prefixes to differentiate them. For example, "core.field1", "custom.field10". As a side effect, it will resolve the problem with conflicts. If someone adds a field ...


0

You can use cookies to maintain client state, because they are a client side storage mechanism. You can use other client side storage mechanisms, for example websql or localstorage. The only problem with the cookies, that session cookies are violating the statelessness constraint. So unless you use session cookies you are okay. You should ask yourself what ...


1

There's HTML5 local storage, which allows you to keep data without it contaminating the HTTP requests you make. It's intended for pretty much exactly this use case: complex Javascript applications that want to store persistent information locally. http://www.w3.org/TR/webstorage/ Note that REST doesn't mean banning all state from the server, sometimes you ...


0

You don't have to use cookies, but if you have secured resources (eg my shopping basket as opposed to your basket) then you do need some way to detect which request corresponds to which of us. That id is usually held in a cookie as the detection is performed on the server via expensive auth mechanisms you want to store temporarily and repeat every request. ...


0

The point that Roy Fielding makes about cookies relates to sending these cookies to the server and maintaining state on the server based on those cookies. Using a cookie purely client-side to store state for any period of time does not violate REST and actually doesn't concern the server-side at all. EDIT: You could store a cookie on a path that is not ...


2

When it comes to API authentication, those are the three most used models (in random order): Credentials are sent with every response. Credentials are sent once to generate an access key. The access key is then sent with every request. Credentials are sent once, and then a session (relying on cookies) is used to avoid repetitive authentication. Since one ...


1

Whenever you define a non-CRUD operation you will be in trouble to find a HTTP method, which describes the same thing. This can be solved by defining a new resource. So REST resources cannot be mapped 1:1 to entities. That's the problem in your case. Imho you need a domain model which is working with the entities and you need a delivery method, which ...


0

You can also mix the special fields with the field names. e.g. /api/items?field1.orderByDesc=value1&field2=value2&field3.orderByAsc=value3 With this approach, you keep the field-specific filters close to the field without having to scan a separate parameter's value. Of course if you have some non-field related special params, such as pagination ...


1

I think you may have a user-process to implementation mismatch here. First: will a user honestly want to perform multiple changes to a file simultaneously? A rename (which may or may not include a change of path?), change of ownership, and perhaps change of file contents (for sake of argument) seem like separate actions. Lets take the case where the answer ...


0

My belief is that you can just send the response from the error handler or test the data before sending if possible. Can also use a preload step during app initialization from your REST interface and store valid value parameters and use those on your client to test data going out. It would be simple to try to send a response from your handler. Garbage ...


1

Rest Api's must be hypertext driven ! As you would click from one link to another in a standard html page. An URL is a unique identifier to a resource. Having an url representing more than one resource is in total disacordance with ReST. With your example, the following url : /api/users/:userId should have a link in its response to the :userId friends ...


2

The first solution has a benefit of avoiding data duplication. The request plainly means: Hello, I'm John. Give me the list of my friends. If possible, I would even shorten it to GET /api/friends. On the other hand, if you expect to be able to access friends of other users, the second solution appears the good one. The request means: Hello, I'm ...


1

An application design like this might be advantageous if you take the broader infrastructure into account. Possibly, your Core project serves more than one other project and combines common business logic across your application infrastructure. Then it might make sense to have it as a separate web application rather than compiled into the same application. ...


1

Within the request and response you send it does not immediately make sense, but I'll give a simpler example. Imagine we'll have a pizza-ordering system, that allows us to order either pizza's (with extra toppings) or soft-drinks (potentially super-sized). To implement our service, we could format it like this: { drinks: [{ brand: 'pipsi', size: ...


0

SOAP follows the Remote Procedure Call paradigm. REST follows, well the REST paradigm. A better question is difference between SOAP and HTTP (SOAP uses HTTP completely wrong) In simple terms RPC is when a client makes a call over the network to a server in order to issue a command on the server. So a client might say "Hey server, update stock price to be 10 ...


5

REST doesn't have anything to say about which controller services which URL. From a purely hierarchical perspective, your first example makes more sense because the first (most general) level in the URL is being handled by its respective controller. i.e. /theaters/:id/movies -- belongs in the Theaters controller, and /movies/:id/theaters -- belongs in ...


1

SOAP is a standardized communications protocol. A SOAP request: POST /InStock HTTP/1.1 Host: www.example.org Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Body ...


2

There is nothing wrong in doing that. Imagine a list of messages which are shown to some groups of users only: one person would see a specific response, another one will see more messages; an administrator will probably see every possible message; a guest won't see anything. You should be careful though. If the form of the response changes radically and ...


1

What other really useful Django features would I lose? "Lose" is probably the wrong way to think about it. Never use and just take up space is probably more accurate. It could be argued that Django is too big a framework for what you are describing. Is there any particular reason why you have to use Django? A micro-framework like Flask might fit the ...


1

As I currently understand HATEOAS is basically all about sending together with each response links with information about what to do next HATEOAS is a lot more than just links. It is "hyper media" as the engine of application state. What is missed in your description is the content type, the formal definition of the hyper media that is passed between ...


1

You don't have to build a dynamically generated interface. Though it could be nice it's not required. If you cannot build a dynamic interface just use the links and you are done. Disadvantage is that you are again hard linked to the backend and will crash if something changes. Using the dynamic layout can be quite simple btw: links.forEach(function(link) { ...


1

Another alternative (using HATEOS). This is simple, mostly in practice you add a links tag in the json depending on your use of hateos. http://api.example.com/games/1: { "id": 1, "title": "Game A", "publisher": "Publisher ABC", "developer": "Developer DEF", "releaseDate": "2015-01-01", "platforms": [ {"_self": ...


0

This is one of those basic questions when it comes to REST API design. Every designer asks themselves this question on the first day. Sorry but the answer is "it depends". Each approach has pros and cons and you'll just need to make a decision and go with it.


1

the app we are building won't simply look at the links and then by itself render the correct UI and make the right ajax calls In fact, this is exactly what HATEOAS will give the UI. Not what is possible, but when it is possible. A formal HATEOAS like HAL, as the question states, gives links that indicate what is possible. But when those links show ...


3

No one said you can't make a URI for /api/foos/?page=1. A container is not the same as the things it contains; a list of foos is a different resource from the individual foos.


1

You should design your backend around the resources you are exposing from the backend. These do not have to match up exactly to your model (the exposed resources and the internal model are two separate things), but often you will have a lot of overlap. For example you might have a "user" model object and a "user" resource exposed by the server. A ...


1

To echo what MainMan said, there are two different concepts at play here, REST and microservices. Your diagram is a micro-service set up. You can do this with RESTful architecture, or with any other architecture. While micro-services and REST are often used together they are not the same thing. REST is a way of thinking about communication between clients ...


2

It seems the most straightforward method is just returning a XML or JSON, with the numbers and status. Per your description, I imagine a structure like this would suffice: { requestDate: '2015-02-05 12:32' results: [{ number: 1, status: 'forwarded', }, { number: 2, status: 'forwarded', }, { number: 3, ...


6

Yes, your understanding is correct. Although, some REST services can be accessed directly, without passing by the server 2. Getting a response is a matter of milliseconds, especially when data centers are close to each other geographically (because indeed, speed of light matters). If we are talking about small web apps, the REST service and the app may be ...


0

For a simple solution that doesn't require you to change the links in the emails, you could have the relevant part of your API respond to requests from user agents in a way that makes sense to an end user. Have your API respond to requests with an accept header containing text/html by redirecting them to a remote resource specified by the business. Allow ...


2

How is the enquiry_id in the "client URL" (that points to a partner's site) generated? If it always matches the enquiry ID that is being used for the URLs you control, then you can simply require that the partners provide a URL template for you to use when setting up an integration with their system. When you generate the email, use the provided URL template ...


1

If each client you intend to service requires different output from your back end. Then write your back-end in a way where is can serve each type. Do some abstraction. Ask yourself, what things will all clients need the same way, and what things will each client need in a specific different way. Put all the stuff that is the same for all clients together, ...


7

An ORM is not a requirement for any project of any scale. More often, small projects start with an ORM, then abandon it when scaling up. If database changes become too complex: Ask yourself why is the database changing too often. I had to work on projects where database was changed at least once per day, just because the project was badly thought, ...


0

The solution I have is to send an API address along with the client auth token. For example, the client will send something like this: api: http://myWebsite/api/clients/ClientA/someServiceCall I don't think it's a good idea. What you are actually trying to do here is to make separate APIs for separate client types. It will quickly become an ...


3

A resource is simply something you can get through an uniform resource identifier (URI), i.e. a piece of information which has an URI associated with it. Imagine an image funny-cat.jpg on your PC; only you can access it. This is not a resource. If, on the other hand, you install an HTTP server which points to the directory containing the image, you can now ...


2

Terms: USER = end user of your client CLIENT = your client API = your server Your example urls: POST /v1/public/{business_name}/enquiries GET /v1/businesses/{business_name}/enquiries/{enquiry_id} Don't do access control in your urls. One resource one url is most simple for your customers to understand. Also: A client can call the following ...


0

My view is that the client is requesting a different representation of the resource i.e. a short one. When you request a different representation (like json or xml) this normally gets tagged at the end of the resource e.g. /some/resource.json, /some/resource.xml So you could take the same logic and do something like /some/resource.short.json



Top 50 recent answers are included