Tag Info

Hot answers tagged

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


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


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


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


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


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


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


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.


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


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


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


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



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