Tag Info

New answers tagged

0

If your credentials are going out with your JavaScript, they can't be kept secret. However, if your credentials are stored on the server, you can keep them secret, by having a server side function use them. In this way, you can examine the incoming request from JS using your server side function, and determine if it's legitimate. If it is legit, you can ...


1

What stops any user to change query string to userid=2000&itemid=55555&itemvalue=100 Nothing. As such you should not make this secure call to the 3rd party from the client app. It should instead be made via your server, as that is the only place you can secure the sensitive authentication information for the 3rd party app. So the client app ...


1

First of this /api/v1/someresource is not actually good REST api design. The version of the api should not be in the path of a resource. A resource is just a resource. The version of the data structure representing the resource should be in the MIME time. For example when you go to a webpage you don't have URLs like this ...


2

Forget about files for a moment. You have an API, and at some point you need to insert identifiers specific to your application. Since your application isn't primarily interested in the features of the API, and because these identifiers are determined without even knowing about the API, you need to be able to translate an arbitrary identifier into ...


1

It sounds like both the API and the website share a common language (PHP). In such a scenario I often find that the functionality used by the API can often be abstracted out into a less API specific object that other solutions (like the website) can also utilize. This object would serve as a shared interface for the website and the API. Very little ...


0

For the moment, as 9000 said, I can't see any real reason to take another approach. However, if design is your main goal, perhaps you should separate your web app from your API server? That way both your web app and your mobile and native apps connect to a uniform REST implementation. Speed at that point is all on your API server, and REST pretty much ...


0

Calling your RESTful services will result in more HTTP connections (and also threads) open on your server. If you are not careful and manage the HTTP client correctly you could leak connections. If the service interface changes, how will you know? Will you remember to update your servlets? Developers would expect the compiler to give some errors. All of this ...


6

You may wish to look into Google Drive API's way of handling this. In their case, paths are abstractions and files are selected by id. A file is a resource. It can belong to a folder, so it has a 'Parents' property. It can belong to multiple folders (either as a shared item, or to simulate soft-links), so it can have multiple 'Parents'. It can be moved to a ...


1

What I usually see is a simple abstraction where Service classes return the data needed in Object form and Rest controller classes render to JSON or whatever you are marshalling to. This would allow you to just reuse the Services for your server side needs and not call back into yourself.


1

You have 2 options : Consuming the REST API using AJAX requests. In this case, your web client will return to the web browser a "static" page, that will retrieve all the needed data using AJAX requests to the REST API. Using this approach, you will transport the main processing in the client side (client meaning the web browser of end users). For an easier ...


2

IMHO, getting list of relevant classes is responsibility of a person. Getting list of people in the class is responsibility of a Class object, and definitely not either of the Controllers' one. Your Person class should have access to ClassService. Your class service should have access to PeopleService. Now, in your PersonController: return ...


4

To list the user departments Use GET /users/<id>/departments, instead of returning this info in the users resource. Doing so allow the below topics to work well in the most RESTful manner - the user-departments relation will always be available under /users/<id>/departments, instead of sometimes available under /users/<id>. To assign an ...


5

You should respond with HTTP 400: Bad Request. The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. The response should include an explanation of why the request was rejected—e.g., “Invalid JSON” .


1

If I'm understanding you correctly, you are providing a list of items with 2 (or more) categories and you want to display them sorted or separated in some way. The options are multiple requests, one for each selected category. Or a single request allowing the client to specify multiple categories. If that's in any way close to the correct understanding, ...


1

The easiest approach if you can accept the drawbacks is to have tomcat as a passive server such that it never contacts the server app. All data flows the other way by periodicly sending heart beats to tomcat and retrieve the json data you mentioned. The drawbacks is that it will (only) be eventual consistent so you will have to accept a small time delay. ...


0

Why should I do it? So we create a form, and we'll have an endpoint where that data can get submitted. Which means anyone can submit data there and see what happens. So we need to validate on two things: that it's being submitted by a user (which .NET will handle for us), and that they're submitting data via a requested form and not just willy-nilly ...


3

I need for my app to consume a rest api service and since I will call it from javascript/jquery i need to expose it to the end user That's your first mistake. As Pinoniq pointed out in his answer, it's not possible to secure client side code. However, you can add your own server to the mix. Have your client side code use JavaScript / jQuery to make a ...


0

I think you should not directly access the Third Party API from your JavaScript application. Instead, you should implement your own basic web services which is like a wrapper around the Third Party API. You can then implement your own authentication method inside your own small web service or do not implement it in case it is not needed. However, you could ...


7

You can't. Let me rephrase: Impossible You could/should make it harder to use a token. Implementing a max-usage per token, a max life-time, ... It is however impossible to know if it is the scriptkiddie or your 'application' contacting your api. A lot of people tend to forget that it is never the aplpication calling the api, it's the application, ...


4

The 'New Post' button would go to a form for the user to input the information for a new post. When the user submits that form the browser rightly sends that data via HTTP POST (use POST for create). An edit submission would use PUT or PATCH depending on whether it is a replace (delete the missing properties) or update (only change the submitted ...


0

From here Although WCF provides some support for writing REST-style services, the support for REST in ASP.NET Web API is more complete and all future REST feature improvements will be made in ASP.NET Web API So for REST services it's preferable to use Web API, not WCF That link also provides some useful info (like whether they are interchangeable, ...


0

REST alone is too primitive, really. You can get started with REST, but eventually, your rich application will need queries with joins and updates with transactions. Every developer attempting to add these things on their own would be error prone and inconsistent. Fortunately, there's an emerging standard called OData that does just that. It layers on ...


1

You should never ( as in never ever EVER) lock any resource while waiting for a user interaction. At some point some of your users will take off for a long weekend leaving some vital records locked. Ah but you won't let that happen because you have some clever time out/deadlock resolution scheme; then at some point this will go horribly wrong and a user ...


1

There are several possible negatives when considering custom header fields. Browser based testing will be difficult Proxies sometimes remove/mangle headers fields It breaks HTTP cacheing Other developers will not expect it When returning a dynamic list, you will want cacheing disabled, so that shouldn't be a problem. If you never expect to use a browser ...


1

Using tokens is very common in APIs, these tokens are usually sent as a header and have a clear life cycle. Think for instance OAuth. Regardless of your programming language or framework, REST APIs are similar. I can think of several scenarios where you want to limit concurrency, two of them are: Multiple clients updating the same resources like a ...



Top 50 recent answers are included