Tag Info

Hot answers tagged

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


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


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


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


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


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


3

I think 403 is the only reasonable response, though 405 Method Not Allowed or 409 Conflict might be acceptable, I don't think either are as good as 403 which states: The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server ...


2

I believe 403 is wrong, because 403 is for situations where you aren't getting access to the resource, and there is no way whatsoever to get access. For your customers, there is obviously a way to get access: Pay up. 401 is truly wrong, because not only are you using it for authentication, but that is what it is there for. Since you are writing an API, I ...


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


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


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


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


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

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

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

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


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



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