Tag Info

New answers tagged

3

404 is perfectly fine for this use case. 4xx status codes are client error codes, so browser treats them as such, and that is perfectly fine too. Another kind of APIs (e.g. JSON-RPC) use different approaches, but since you're going RESTful, do not change response code just to make console output look pretty - it is not a use case, users are not supposed to ...


0

You should architect the API around resources, not around roles, e.g.: /rest/students should be accessible to anyone with a role that allows them to see students. Internally, you are implementing role-based security. How you go about that depends on the details of your application, but let's say you have a role table, each person has one or more roles, ...


0

You should return a 4xx error with a detailed description of the reason the request failed in the response body. Can't help with the Java implementation. In many Python frameworks you would throw a 4xx exception as soon as your code has determined that the HTTP request is going to fail and this is caught by the framework and returns a 4xx HTTP status ...


1

You simply don't give the user access to that API. For example, we have several web apps which uses access tokens and bill the user for certain actions. The billing system is centralised, and there's an app used by our customer services to add credits to the bills. But there's no reason why the access token the end user gets to perform the actions on the ...


2

One thing to keep in mind is the expected network latency (i.e. ping time) between your clients and your server. In a high-latency situation with otherwise good bandwidth, many small requests will perform significantly worse than one large one. I've recently been collaborating on a multi-team database-backed web application project in which one of the ...


3

No. REST doesn't care about how your organize your resources, only that individual resources are identified by URLs and that resources are discoverable from other resources. If api/competitions/{id}/teams/players makes sense for your application then use it, as long as users can find a link to it. Roy Fielding's dissertation on Representational State ...


5

There are two ways you can view your diagnostic information: part of an existing resource, or a separate resource. How you view it depends on your application requirements. If the information is part of an existing resource, then you have the most "RESTful" representation possible. Note that REST does not strictly place requirements on the structure of your ...


1

Based on just the info you gave, option 1, because with a single client request you'd be mixing apples and oranges and the fruit basket might be very large. caching is a tradeoff where you gain performance but potentially lose consistency (stale data). If you don't have any identified performance issues, synchronization problems are usually not worth ...


0

As always in programming, it depends. So, the real question is: what should you consider when deciding for A/B/C or a combination of the three? I would say that the real discriminating factors are the implementation details of the 3rd party APIs you are consuming. As an example, you should consider: Are they fast or slow? Do data changes frequently and ...


3

If you allow a client to access the database directly - which they would do, even with a database abstraction layer, then: You get a coupling between their code and yours - particularly, there is a very strong coupling between your database structure and their code; Your client may do some pretty undesirable stuff on your database - whether it be updating ...


0

Just because you're inside the same company doesn't mean you should expose everything to everyone. REST APIs are a way to define a limited consumer/provider relationship between teams in a company, with a clear contract. Amazon has been a pioneer in this form of organization. APIs also provide a layer of abstraction, allowing you to use a specific set of ...


1

If I understand correctly what a DBAL is, then the answer is that a REST interface allows you to use any language for its clients, while a DBAL is a library that allows you to use a single language for its clients. This, in turn, can be an advantage for a company where there are many development teams and not all of them are proficient in the same language. ...


1

You are thinking that REST is for database queries and it is not. REST represents the state of something at the moment. Using REST changes or retrieves a representation but that is all. If that state becomes available by database, it doesn't matter and no one cares because HOW that representation comes to be is not part of REST and neither are database ...


0

These three options are not mutually exclusive, you can use an combination of both client-side and server-side caches. However some of data, like comments, may become stale, if kept in cache for too long. Considering you can't check whether that is the case, you should probably refrain from storing it at all. On the other hand content usually doesn't change ...


0

I would (almost) discount option 3. Choosing between 1 and 2 depends on two things: (A) how big the result of a single, total fetch is (B) how much of the detail of the result the client/user will typically use in that session. It's easy to make a decision if A and B are extremes: If A is large and B is small, definitely go for option 1 (A la Carte). ...


4

Hypermedia never really got popular with REST-like APIs - to the point that when an API actually implements hypermedia navigation, the term RESTful simply isn't enough to distinguish it from any other "RESTful" web APIs. REST has become an catch-all term or any resource-based web APIs and new names like Hypermedia API have been coined to focus on ...


1

You can call it a Web API. It's a very broad term but it can avoid nitpicking about meaning of other API type definitions. The term is less technical and precise compared to alternatives like HTTP API, but that might be an advantage when talking to non-technical people. This term is also used by Leonard Richardson (who defined the Richardson Maturity Model ...


1

You can call it whatever you like, people tend to (almost religiously) latch onto any part of the REST 'spec' that you're not following and use that as a point of protest which is highly detrimental to the development. But that said, the simple fact is that there are (nearly) zero services exist that implement true REST for their API serves. In our team we ...


30

Call it an HTTP API. It conforms to HTTP standards, and doesn't have anything else layered on top (e.g. SOAP). The HTTP standards define resources, verbs, headers, content negotiation, etc. REST (REpresentational State Transfer) is an architecture with requirements that happen to be amenable to existing HTTP standards, but HTTP works on all its own. ...


17

Richardson Maturity Models goes like this POST everywhere. A single endpoint. (SOAP) POST everywhere. Multiple endpoints. (resources) HTTP VERBS. Multiple endpoints. Like 2 and returns links to resources. (RESTful) So according to the model I would call it a webservice conforming to richardson level 2 or something along those lines. ...


2

It is a CRUD interface (Create, Read, Update, Delete) over HTTP. I can't think of any authorities to back it up this assertion, so I hope you get more and better answers.



Top 50 recent answers are included